Mail Archives: djgpp-workers/1999/07/05/15:42:12
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 <sys/stat.h>
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 <sys/socket.h>
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
> <sys/stat.h> 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 !!!
- Raw text -