Re: More POSIX Issue 8 changes (msg #2)

2020-03-29 Thread Robert Elz
Date:Sat, 28 Mar 2020 21:24:18 +0100
From:Rhialto 
Message-ID:  <20200328202418.gb27...@falu.nl>

  | There seems to be a mistake in that text:

Yes, that looks to be incorrect.   And the other issue (which is more
important, shortest or leftmost, also looks to be a real issue that
needs documenting.

  | Where does one report such mistakes?

Same web page (URL) - up near the top (left side) you'd see a "login"
link, if one uses that, and logs in, the page contains a form at the
bottom where notes can be added.   There used to be a "register: link
there which would give you a login name/password to use (well, give you
a form on which you selected those) but it was being abused by spammers,
so was deleted.  To get a login name now, send e-mail to Andrew Josey
( and ask (suggest what login name you'd like).
This is just spammer prevention, they still give out login names to
anyone who asks.

Alternatively, e-mail to austin-grou...@opengroup.org the mailing list
for the group, sorry, I forget how one subscribes to that list, it has
been a long time, and I suspect things have changed...   But Andrew would
be able to tell you that as well.   (He's based in London (well, the UK
somewhere) I believe, so close enough to your timezone for rapid (weekday
anyway) turnaround of messages.

Or, I could do one of those on your behalf (as could Steffen I believe,
who already replied to your message).   There are, or have been, other
NetBSD users on the austin-group list as well.

kre



Re: More POSIX Issue 8 changes (msg #2)

2020-03-28 Thread Steffen Nurpmeso
Rhialto wrote in
<20200328203055.gc27...@falu.nl>:
 |and I'm not so sure about the text that follows:
 |
 |whereas the ERE ".*?c" matches the first character 'c', the third
 |character in the string.  [[ "abc abc" ]]
 |
 |Possibly it should match "abc", because that is leftmost; just matching
 |"c" is shortest but I don't see it as being leftmost. I'm not sure how
 |rigorous they define these terms.

I like Hermann van Veen.  This is in German though.

  https://www.youtube.com/watch?v=dlgejLidA6A

 --End of <20200328203055.gc27...@falu.nl>

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)


Re: More POSIX Issue 8 changes (msg #2)

2020-03-28 Thread Rhialto
and I'm not so sure about the text that follows:

whereas the ERE ".*?c" matches the first character 'c', the third
character in the string.  [[ "abc abc" ]]

Possibly it should match "abc", because that is leftmost; just matching
"c" is shortest but I don't see it as being leftmost. I'm not sure how
rigorous they define these terms.

-Olaf.
-- 
Olaf 'Rhialto' Seibert -- rhialto at falu dot nl
___  Anyone who is capable of getting themselves made President should on
\X/  no account be allowed to do the job.   --Douglas Adams, "THGTTG"


signature.asc
Description: PGP signature


More POSIX Issue 8 changes (msg #2)

2020-03-26 Thread Robert Elz
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  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  - 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  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  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