S_ISCHR, S_ISFIFO, O_NONBLOCK, O_NOCTTY

Melissa O'Neill oneill@cs.sfu.ca
Fri Feb 5 13:13:00 GMT 1999


Zack wrote:
>>> Either way, that's gonna hit the "not a file, pipe, or tty" case.  Can
>>> you do `cat | ./cpp' on a nextstep box to confirm this?

... and I, naively, replied:
>> Running `cat | ./cpp' on my NEXTSTEP 3.3 machine appears to work.

... leading Zack to ask:
> you please verify that ./cpp is cpplib-based

Well, I don't specify any special arguments to ./configure (other than
--prefix), so if cpp isn't cpplib-based by default, my cpp wouldn't be
cpplib based.

>From my build log, it looks like my cpp is cccp, and cccp is made from
cccp.o, cexp.o, intl.o, prefix.o, version.o, mbchar.o, obstack.o and
libiberty.a.

However, taking a guess at how to make a cpplib based cpp, I tried making
cppmain (which appears to use cpplib) and my previous test results stand.
i.e.

	nextstep3.3% echo 'FOO' | ./cppmain -DFOO=BAR
	# 1 ""
	BAR

Zack continues:
> The only way I can see for this to happen is if S_IFREG is zero, in
> which case a socket will be erroneously detected as a file.  Since
> st_size would be zero, that should send the reader into an
> infinite loop.
>
> What is the actual value of S_IFREG?

On NEXTSTEP, S_IFREG is 0100000 (octal).
			
I investigated further, adding the line:

	  fprintf(stderr, "DEBUG: st.st_mode = %o\n", st.st_mode);

to finclude in cppfiles.c, and found, to my surprise, that st.mode for
the pipe was '0010666', and S_IFIFO is defined in sys/stat.h and is set
0010000, so my NEXTSTEP machine *is* setting the mode as you would expect
on a machine with FIFOs. (NEXTSTEP 3.x has some rather broken POSIX
support, including FIFO support for designated POSIX applications, so
perhaps I shouldn't have been all that surprised).

Of course, this discovery means that the man page for fstat is wrong,
but we shouldn't be surprised about that...

In his earlier message, Zack had also asked:
>>> My documentation is inconsistent - what does shutdown do when asked
>>> to disallow sends and sending is already shutdown?

... and I had replied:
>> On my NEXTSTEP machine, using AF_INET sockets, the second call succeeds
>> and appears to be harmlessly redundant.

... leading Zack to wonder:
> Was the socket in question connected to anything?

Yes.  It was connected to a TCP echo server.  (In fact, the code was
heavily based on example in Richard Steven's _Unix Network Programming,
volume 1, 2nd edition_, page 162, duplicating the call to shutdown.)

Best Regards,

    Melissa.



More information about the Gcc-patches mailing list