Date: Tue, 6 Jul 1999 13:14:55 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Alain Magloire <alainm AT rcsm DOT ece DOT mcgill DOT ca>
cc: djgpp-workers AT delorie DOT com
Subject: Re: Request: S_IFSOCK & S_ISSOCK in sys/stat.h
In-Reply-To: <199907051941.PAA22024@spock2.ECE.McGill.CA>
Message-ID: <Pine.SUN.3.91.990706131434.17419G-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
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


On Mon, 5 Jul 1999, Alain Magloire wrote:

> I don't understand the mknod() question, mknod() refers to a creation
> of a file where S_IFIFO is probably the only portable argument.

mknod was only an example.  The idea is that a functionality could
exist in the library as a stub that doesn't do anything useful.  For
example, mknod succeeds for S_IFREG, but fails for everything else.
But if mknod does NOT exist, you will get link errors, which is bad.

A more appropriate example is the one with S_ISLNK: many programs
assume that if S_ISLNK is defined, the library has a symlink function,
so you have code like this:

   #ifdef S_ISLNK
     if (S_ISLNK (statbuf.st_mod))
        symlink (foo, bar);
   #endif

In other words, if you advertise S_ISLNK, you had better provide a
symlink function that does something sensible.  At the very least, if
no file will ever cause S_ISLNK to return non-zero (which is analogous
to S_ISSOCK without libsocket), you need to provide a version of
symlink that always fails.  But you do need to provide *some* version
of symlink, or else programs simply won't link.

The problem (my problem) is to identify the minimal set of
functionality that is implied by S_ISSOCK being defined.  I looked
into some GNU packages and only found the filemode function that uses
it.  If that is the only functionality that we should care about, then
there's no problem to add S_ISSOCK to sys/stat.h right now.

> 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.

If *all* the functionality implied by S_ISSOCK is inside libsocket on
other platforms, then we should have no problems at all if we add
S_ISSOCK to sys/stat.h.  Things I was worried about are some
socket-specific features in functions like dup, select, ioctl, etc.

Bottom line: if nobody objects, we could add S_ISSOCK now and see if
it does any trouble during v2.03 beta.

Is there anything else, besides S_ISSOCK, that should be added?