Re: FYI: POSIX update - SIGWINCH and 'struct winsize' (etc) to be added

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Sun, 22 Oct 2017 06:32:26 +0200
    From:        Kamil Rytarowski <n54%gmx.com@localhost>
    Message-ID:  <4aceadc4-7cd6-989d-c9cb-abaa8e103fbd%gmx.com@localhost>

  | What UNIX-like systems skip ioctl(2)s

Probably none, since 7th edition (there was no ioctl before that)
but posix does not define ioctl, so anything which claims to be
_POSIX_SOURCE (only) cannot legitimately be using ioctl().

  | We have a reversed logic compared to GNU. In GLIBC
  | additional namespace definitions include additional features instead of
  | hiding existing ones.

Not really (aside from quoting glibc as being an example of how things
should be done is usually just funny) - apps can define as many of those
symbols as they need, the lines from featuretest.h that I quoted are
just picking the default.

That is, for apps that know nothing about any of this stuff, get
_NETBSD_SOURCE (which is, more or less, everything.)

On the other hand, an app that knows enough to say it it needs _POSIX_SOURCE
should be given exactly that - if it also wants more, it should know how
to ask for more, not get more thrown in just for fun - and this is important,
as all the extra that is included is limiting the namespace available to
the application - POSIX defines what symbols can be present (without the
app explicitly asking for more) from any header, only those should be
provided.   Nothing in POSIX allows for "ioctl()" or TIOCxxxx names to
exist, so a posix application is entitled to assume that it is free to
use any of those names for its own purposes.

That there are broken applications from the gnu world which have no
idea what they're doing, or why, shouldn't really deter us from doing
this correctly.

  | I think that 1 vnode optimization is a nanooptimization.

inode, not vnode (the latter only exists in /dev/mem and is irrelevant here).

I agree about that one (and the block the file would occupy) they don't
really matter, but the extra compile time, of opening and reading this
extra file all the time, is not quite so easy to disregard, nor is
maintaining a new file, forever, a non-negligible cost.

  | I'm personally for adding a new header.

That still might be what happens (it is what I am using to test with at
the minute), if none of the other solutions ends up being good enough.

That is the one that is both clean and effective.

(Kind of like you can always get a Mercedes that will work well, but
there might just be something cheaper that is good enough that would be
a more pragmatic choice...)

kre