From: Alain Magloire Message-Id: <199907051941.PAA22024@spock2.ECE.McGill.CA> Subject: Re: Request: S_IFSOCK & S_ISSOCK in sys/stat.h To: djgpp-workers AT delorie DOT com Date: Mon, 5 Jul 1999 15:41:03 -0400 (EDT) In-Reply-To: from "Eli Zaretskii" at Jul 5, 99 10:35:29 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Reply-To: djgpp-workers AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk Bonjour > On Sun, 4 Jul 1999, Richard Dawe wrote: > > > I was wondering if it would be possible to add definitions for S_IFSOCK > > and S_ISSOCK to sys/stat.h: > > > > #define S_IFSOCK 0x6000 > > #define S_ISSOCK (((m) & 0xf000) == S_IFSOCK) > > > > Some value other than 0x6000 could be used. > > > > I ask because it would make writing libsocket's stat() support easier. No > > patches to sys/stat.h would be required, which is easier not only for me, > > but also end users of the library. > > We need to establish whether libsocket supports all the features that > the existence of S_IFSOCK indicates. This support can be degenerate, > like what we do in `mknode', but it must be there, or else some > program that ifdef's code conditioned on S_IFSOCK will do the wrong > thing. S_IFSOCK is part of Posix.1g now, it reflects the desire of the commitee to move away from ioctl()/fcntl(). They define isfdtype(int, int) #include int isfdtype( int filedes, int fdtype ); The isfdtype() function determines whether the file descriptor filedes has the properties identified by fdtype. int fd = socket (..); if (isfdtype(fd, S_IFSOCK)) { // socket .. } The document Posix1003.1g only required support for fdtype == S_IFSOCK > I don't know enough about either sockets or libsocket to tell how > close we are to that goal. Can you look into this issue and post here > what you find? A note, The changes/hooks requested are general and apply to any socket libs. Meaning they are not specific to libsocket, they are the normal hooks that libc must have to support a networking lib. S_IFSOCK is a bit different/new. POSIX.1g wanted a std way, not via the non-portable ioctl(), to identified a socket fd, the same as isatty() or isastream(). Hence isfdtype() and the macro S_IFSOCK But even before POSIX.1g lots of Un*x had S_IFSOCK/S_ISSOCK(). I don't understand the mknod() question, mknod() refers to a creation of a file where S_IFIFO is probably the only portable argument. For example a way to implement isfdtype() is to let FSEXT do the magic : int isfdtype (int fd, int fd_type) { struct stat buf; if (fstat (fd, &buf) == 0) { if ((buf.st_mode & S_IFMT) == fd_type) return(1); } ... } > In addition, there's a problem of having S_IFSOCK without libsocket > being installed. Does this present a problem in the sense of > (un)supported features that programs which use S_IFSOCK assume? > Again, I don't have the answer. My 0.02$ Euro, that is not a problem. The macro refers to sockets and most script will try to do a socket call #include int main() { socket(..);..} by linking with -lsocket -lnls(For Solaris) to check the existence of a Socket API before checking any specific features of that API. This is an excellent question, that deserve a clear answer. Some people are working on alternative libs to enhance DJGPP for ex: support for networking, threads, I18n, A I/O, rpc, etc .. It is not necessary to fold everything back and probably not recommended. But I think making things easier, by for exam: having a wider range of errno, or new macros etc .. can be a plus But you got a somewhat similar problem with any Un*x, you have different hooks in the headers for libs, so the program must be link with -lpthread, -lthread, -lintl, -lw, -lsocket, -lnsl, -laio, -lnis, -lmp, -lmail, etc .... The problem with DJGPP, those libs are consider like 3rd parties and may not be part of the dist, like for Solaris, AIX > If having S_IFSOCK without libsocket can be a problem, we could make > include some internal header that will be empty in djdev > and will be replaced by libsocket installation; then this internal > header could define S_IFSOCK. > 8-) is it a viable solution ? -- au revoir, alain ---- Aussi haut que l'on soit assis, on est toujours assis que sur son cul !!!