delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/1999/07/05/15:42:12

From: Alain Magloire <alainm AT rcsm DOT ece DOT mcgill DOT ca>
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: <Pine.SUN.3.91.990705103509.278I-100000@is> from "Eli Zaretskii" at Jul 5, 99 10:35:29 am
X-Mailer: ELM [version 2.4 PL25]
MIME-Version: 1.0
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

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 -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019