More POSIX Issue 8 changes (msg #2)

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

With all the same caveats, etc, as were in the first of these
messages...


c99 is to be required to process .i files - that is, the output from cc -E
and so means compiling them like a .c file, except without the preprocessor
step.
URL: https://austingroupbugs.net/view.php?id=667 


Two related issues:
posix_fallocate() is allowed to return ENOTSUP if the filesystem doesn't
support it (but if the posix_fallocate option is included, there must be
at least one filesystem which does support it - what that means - as in,
actually mounted, or could be mounted, or could be compiled into the kernel,
or could be loaded as a module from soe 3rd party vendor, is not stated).
URL: https://austingroupbugs.net/view.php?id=684 

And <unistd.h> is to include _POSIX_FALLOC (as an arg for fpathconf() to
indicate if posix_falloc() is supported) and _PC_FALLOC (as the value
returned from fpathconf() when _POSIX_FALLOC is used, and as an arg
for pathconf() to determine if posix_falloc() is supported on a particular
filesystem.   For the details, see:
URL: https://austingroupbugs.net/view.php?id=687 


setreuid() and setregid() are added to the list of async signal safe
functions (I can't imagine that bothers us at all).
URL: https://austingroupbugs.net/view.php?id=699 


The stdarg va_*() macros are added to the list of async signal safe functions
(henceforth called "async signal safe functions and function-like macros")
URL: https://austingroupbugs.net/view.php?id=711 


A whole bunch of changes to the way the Bessel functions (y0() y1() yn())
(whatever they are, I'm not a mathematician) are specified (I gather,
so they become mathematically correct).
URL: https://austingroupbugs.net/view.php?id=714


NSIG_MAX is to be added to <limits.h> - to specify a number of signals
guaranteed to fit in a sigset_t (regardless of whether the implementation
actually supports that number of signals).
For us, that would be 128 (or maybe 127?)
_SC_NSIG is to be added to <unistd.h> as an arg for sysconf() to return
the highest signal number (+1) supported by the (current) system (ie: all
signals will be 0 < signum < sysconf(__SC_NSIG) ).   The value has to be
bigger than SIGRTMAX.   (For current NetBSD I'd assume this will return 64,
but I suppose could be 128 if the kernels support that many - it can vary
from port to port if needed.)
For the details see the URL (and ignore the notes added by shware_systems
which are nonsense).
URL: https://austingroupbugs.net/view.php?id=741 


ERE's gain the ability to match shortest (minimal, including empty where
the actual expression allows it) leftmost strings (as an alternative to
the normal longest possible leftmost match).   I'm not sure I follow
everything that's in this one, so see the URL, but I believe the idea
is that
	ab*?
will match just "a" regardless of how many b's follow it,
and
	a[bc]*?c
matched against abbbcbbbcbbbcd  would match abbbc rather than abbbcbbbcbbbc
There is also a new flag REG_MINIMAL which changes the default match for
ERE's from longest to shortest match.
URL: https://austingroupbugs.net/view.php?id=793 


getsockopt() is to have 2 new (getsockopt only, no set) options
SO_DOMAIN and SO_PROTOCOL (returning the values used in the socket()
operation, or what was chosen if that didn't specify one).
URL: https://austingroupbugs.net/view.php?id=840 


The M_* constant definitions in <math.h> are being tightened - it will
now be required that (double)M_PI == M_PI always (it wasn't before, as
some implementations (ours?) specify long double values, which when rounded
don't always compare equal that way.   That's no longer permitted.
Instead, a whole new set of M_*l (that's a lower case L suffix appended
to the name) definitions are added, with the long double variants of each
of the M_* constants,  (eg: there will be both M_PI and M_PIl if you can
take the 2nd of those seriously!  Also M_E and M_El ...)
See the URL for the details of exactly what is required.
URL: https://austingroupbugs.net/view.php?id=828 



That's it for this set (and to repeat, all of these are now in the
text of what will be the next POSIX standard ... it isn't yet easily
available anywhere though.)

kre