C11/POSIX-2024 Questions
Joel Sherrill
joel.sherrill@gmail.com
Mon Aug 19 19:53:51 GMT 2024
I thought I would return to the question of what value _POSIX_C_SOURCE
should have.
Issue 8 HTML is on the opengroup.org site now.
https://pubs.opengroup.org/onlinepubs/9799919799/functions/V2_chap02.html
Has it as 202405L.
Brian is there any reason to think it could also be 202406L now?
--joel
On Fri, Jun 28, 2024 at 5:34 PM <brian.inglis@systematicsw.ab.ca> wrote:
> POSIX is also ISO/IEC JTC 1/SC 22/WG 15 ISO/IEC 9945:2024 in DIS ballot.
>
> Probably easier to look for changes from drafts and propose changes and
> comments, then wait for both ISO/IEC ballots to pass or ISO/IEC updates to
> be
> cancelled, before applying updates.
>
> On 2024-06-28 16:01, Joel Sherrill wrote:
> > Thanks everyone. I guess the broader question with multiple
> > standards being released close to each other, is do we need
> > a master plan? Or just fix things as they are spotted.
> >
> > It seems there are a number of things to address this time.
> >
> > --joel
> >
> > On Fri, Jun 28, 2024 at 4:33 PM <brian.inglis@systematicsw.ab.ca
> > <mailto:brian.inglis@systematicsw.ab.ca>> wrote:
> >
> > On 2024-06-28 08:37, Joel Sherrill wrote:
> > > Hi
> > >
> > > I am finishing up reviewing the additions from POSIX Issue 8
> which was
> > released
> > > recently. I noticed a few things and have questions on the right
> approach.
> > >
> > > + I only have the final draft for POSIX-2024. It says
> "_POSIX_VERSION to
> > the value
> > > 20yymmL." It isn't on the web yet for the HTML version. Anyone
> know the
> > value
> > > this has in the final version?
> >
> > The Austin Group minutes say in:
> >
> >
> https://www.mail-archive.com/austin-group-l@opengroup.org/msg12711.html
> > <
> https://www.mail-archive.com/austin-group-l@opengroup.org/msg12711.html>
> >
> > "The IEEE and The Open Group pdf edition was published on Friday
> June 14th."
> >
> > so I would expect POSIX-1.2004/IEEE Std. 1003-1(2024) to have
> 202406L date.
> >
> > Another email states it could take another month for the HTML ~July
> 21.
> >
> > > + sys/features.h appears to need this new POSIX version added at
> least to
> > the
> > > comment block. I don't think it necessarily changes any logic
> below that.
> >
> > The latest draft normative references include ISO/IEC 10646:2020
> (6th edition)
> > so Unicode should be at least 13 dated 2020-03-06 and
> __STDC_ISO_10646__ at
> > least 202003L.
> > This was amended by ISO/IEC 10646:2020/Amd1:2023 2023-07-17 so
> Unicode could be
> > up to 15.0 dated 2022-09-09 with __STDC_ISO_10646__ 202209L.
> > There were no amendments for Unicode 14 2021-09-10 or 15.1
> 2023-08-28.
> > Future considerations expect Unicode 16 in Amendment 2:2025.
> >
> > ISO/IEC JTC 1/SC2 WG2 is no longer at
> http://std.dkuug.dk/jtc1/sc2/wg2
> > <http://std.dkuug.dk/jtc1/sc2/wg2>
> > (NXDOMAIN) so old working documents are no longer available but has
> moved to
> > https://www.unicode.org/wg2/ <https://www.unicode.org/wg2/> where
> more
> > recent working documents are available,
> > and hopes are that ISO/IEC standards can be stabilized with normative
> > references
> > to Unicode specs like UTS Unicode Technical Standards and UAX
> Unicode Standard
> > Annexes.
> >
> > > + memmem is in string.h under the __GNU_VISIBLE guard. Does it
> now need
> > to be
> > > under a __POSIX_VISIBLE > 2024mmdd and __GNU_VISIBLE?
> > >
> > > + aligned_alloc in stdlib.h is only guarded by C > 2011. Does
> that need
> > to be an
> > > || POSIX >= 2024 also?
> > >
> > > + C11 and POSIX-2024 add these complex methods.
> > >
> > > double complex CMPLX(double x, double y);
> > > float complex CMPLXF(float x, float y);
> > > long double complex CMPLXL(long double x, long double y);
> > >
> > > FreeBSD has a macro implementation
> > > (
> https://github.com/lattera/freebsd/blob/master/include/complex.h#L49
> > <
> https://github.com/lattera/freebsd/blob/master/include/complex.h#L49>
> > > <
> https://github.com/lattera/freebsd/blob/master/include/complex.h#L49
> > <
> https://github.com/lattera/freebsd/blob/master/include/complex.h#L49>>).
> If I
> > > add that to complex.h, does it also need a __ISO_C_VISIBLE >=
> 2011 ||
> > > __POSIX_VISIBLE > 2024mmdd guard?
> >
> > The same minutes linked above says:
> >
> > "The ISO/IEC [POSIX] ballot closes on June 28."
> >
> > Also note that ISO/IEC 9899:2024 C is targeted for July 12, and JTC
> 1/SC 22/WG
> > 14 hope to get that passed by some picky ISO editors in time, or it
> will be
> > cancelled for this year.
> >
> > So look for ISO C >= 2024 and add changes, including docs and
> compiler options,
> > and note 202X is becoming ambiguous so groups are using 202Y.
> >
> > > + Should I continue to look for guards on things that are newly
> added in
> > POSIX
> > > 2024 and already in newlib?
> > >
> > > That's it so far. Just picky stuff that I plan to address given
> some advice.
> >
> > I am also waiting to see if this will be issued as SUSv5?
> >
> > --
> > Take care. Thanks, Brian Inglis Calgary, Alberta, Canada
> >
> > La perfection est atteinte Perfection is achieved
> > non pas lorsqu'il n'y a plus rien à ajouter not when there is no
> more to add
> > mais lorsqu'il n'y a plus rien à retirer but when there is no
> more to cut
> > -- Antoine de Saint-Exupéry
> >
>
> --
> Take care. Thanks, Brian Inglis Calgary, Alberta, Canada
>
> La perfection est atteinte Perfection is achieved
> non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to
> add
> mais lorsqu'il n'y a plus rien à retirer but when there is no more to
> cut
> -- Antoine de Saint-Exupéry
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://sourceware.org/pipermail/newlib/attachments/20240819/363e2faa/attachment.htm>
More information about the Newlib
mailing list