S_ISCHR, S_ISFIFO, O_NONBLOCK, O_NOCTTY

Zack Weinberg zack@rabi.columbia.edu
Thu Feb 4 12:22:00 GMT 1999


On Thu, 04 Feb 1999 14:46:52 -0500, Dave Brolley wrote:
>I'll admit that this kind of stuff is not something I know a lot about. Anyone
>out there have any comments on this patch?

Well, as the perpetrator of the changes...  Melissa's patch looks
entirely sane to me, except for one thing:

>> Similarly, cppfiles.c now tests file types using S_ISFIFO and S_ISCHR.
>> Some Unix systems don't have FIFOs, and non-POSIX systems do not have
>> these macros.

On systems without FIFOs, what does fstat() return for stdin when
stdin is an anonymous pipe?  The check is applied to the main input,
so it's relevant.  We don't want to disallow piping to cpp by accident.

>> P.S.  I'm not sure what the addition of O_NONBLOCK and O_NOCTTY is supposed
>> to achieve, so I don't know whether my substitution of O_NDELAY for
>> O_NONBLOCK and 0 for O_NOCTTY is entirely acceptable.

It's extra bulletproofing.  Some device special files will block you
in open() if you don't use O_NONBLOCK.  Thus we would never get to the
code that tests for a device and rejects it.  O_NDELAY has identical
semantics in this case, so that part of the patch is safe.

O_NOCTTY is included to avoid an extra pathological case: if the
preprocessor is running without a controlling terminal (say, from a
cron job) and it opens a terminal device, that terminal will become
controlling.  If anyone is logged on that terminal, they can then send
job-control signals to the preprocessor by accident.  This could cause
inexplicable failures.  O_NOCTTY prevents this.  AFAIK, systems that
don't have O_NOCTTY don't reassign controlling terminals to background
jobs, so again this is safe.

I should've thought of these problems myself; I've gotten spoiled by
modern OS's.

zw


More information about the Gcc-patches mailing list