Xref: utzoo comp.unix.questions:15273 comp.unix.wizards:17405
Path: utzoo!attcan!uunet!auspex!guy
From: guy@auspex.auspex.com (Guy Harris)
Newsgroups: comp.unix.questions,comp.unix.wizards
Subject: Re: Portable mknod ?? does it exist?
Keywords: mknod
Message-ID: <2308@auspex.auspex.com>
Date: 29 Jul 89 06:37:11 GMT
References: <178@cerc.wvu.wvnet.edu.edu>
Reply-To: guy@auspex.auspex.com (Guy Harris)
Organization: Auspex Systems, Santa Clara
Lines: 27

>Does anyone have any suggestions on how to make this portable ?

Well, the "mknod" is a perfectly legitimate call, according to the SVID
(all of the vendors are presumably at least trying to follow the SVID
there, although ultimately they'll all go with POSIX and support
"mkfifo()" also), so the HP implementation is buggy.

The "open" call passes O_RDWR, and the SVID doesn't say anything about
opening a FIFO with that mode, so the DEC implementation is OK according
to the SVID and POSIX (POSIX quite explicitly says the behavior when
O_RDWR is passed is undefined), although it might have been nice had
they made it work (ENXIO is kind of a rude error to return on that), and
made it work the way they do in S5....

Given that the "open"'s behavior isn't specified by the SVID, the
"read"s behavior can't be specified either, although again it might have
been nice had SGI made it work the way it appears to work in the
S5 code - i.e., the "read" blocks, since somebody has the pipe open for
writing but no data's been written but unread....

I'd suggest *not* opening it for reading and writing, but instead open
it for reading and separately open it for writing (presumably, the whole
point of the exercise is to have two unrelated processes communicate, so
one would open it for reading and another would open it for writing). 
That might stand a better chance of working on the DEC and SGI systems. 
Unfortunately, that still doesn't help with the HP system, so yell at
HP....