* C11/POSIX-2024 Questions
@ 2024-06-28 14:37 Joel Sherrill
2024-06-28 16:00 ` John Scott
2024-06-28 21:32 ` brian.inglis
0 siblings, 2 replies; 5+ messages in thread
From: Joel Sherrill @ 2024-06-28 14:37 UTC (permalink / raw)
To: Newlib
[-- Attachment #1: Type: text/plain, Size: 1345 bytes --]
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?
+ 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.
+ 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). If I
add that to complex.h, does it also need a __ISO_C_VISIBLE >= 2011 ||
__POSIX_VISIBLE > 2024mmdd guard?
+ 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.
--joel
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: C11/POSIX-2024 Questions
2024-06-28 14:37 C11/POSIX-2024 Questions Joel Sherrill
@ 2024-06-28 16:00 ` John Scott
2024-06-28 21:32 ` brian.inglis
1 sibling, 0 replies; 5+ messages in thread
From: John Scott @ 2024-06-28 16:00 UTC (permalink / raw)
To: Newlib
[-- Attachment #1.1: Type: text/plain, Size: 1506 bytes --]
> 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?
I assume you're referring to Draft 4.1, which indeed just has the placeholder. I don't have the final version, but the latest "interim build draft" had 202405L. I expect that this has not changed since this corresponds to the month that it was sent out for publication.
> memmem is in string.h under the __GNU_VISIBLE guard. Does it now need to be under a __POSIX_VISIBLE > 2024mmdd and __GNU_VISIBLE?
ISO C has reserved symbols starting with "str" and "mem" in <string.h> to the implementation at least since C99, and POSIX affirms this, so technically it does not, and has never needed, a guard at all. It can be exposed even in strict ISO C conformance mode unconditionally. This extends to strlcpy, strlcat, stpcpy, and friends too.
> aligned_alloc in stdlib.h is only guarded by C > 2011. Does that need to be an || POSIX >= 2024 also?
POSIX 2024 *requires* C11/C17: if someone has _POSIX_C_SOURCE set to 202405L but __STDC_VERSION__ < 201112L, that's not a conforming build environment and it's basically an error on the part of the user. I therefore don't think this deserves special accommodation: a conditional on the ISO C version should be adequate.
Please note: I'm basically an amateur who lurks here and in the Austin Group and you should have healthy skepticism over my opinions here.
[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 6270 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: C11/POSIX-2024 Questions
2024-06-28 14:37 C11/POSIX-2024 Questions Joel Sherrill
2024-06-28 16:00 ` John Scott
@ 2024-06-28 21:32 ` brian.inglis
2024-06-28 22:01 ` Joel Sherrill
1 sibling, 1 reply; 5+ messages in thread
From: brian.inglis @ 2024-06-28 21:32 UTC (permalink / raw)
To: newlib
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
"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
(NXDOMAIN) so old working documents are no longer available but has moved to
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>). 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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: C11/POSIX-2024 Questions
2024-06-28 21:32 ` brian.inglis
@ 2024-06-28 22:01 ` Joel Sherrill
2024-06-28 22:32 ` brian.inglis
0 siblings, 1 reply; 5+ messages in thread
From: Joel Sherrill @ 2024-06-28 22:01 UTC (permalink / raw)
To: newlib
[-- Attachment #1: Type: text/plain, Size: 4153 bytes --]
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> 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
>
> "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
> (NXDOMAIN) so old working documents are no longer available but has moved
> to
> 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>).
> 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
>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: C11/POSIX-2024 Questions
2024-06-28 22:01 ` Joel Sherrill
@ 2024-06-28 22:32 ` brian.inglis
0 siblings, 0 replies; 5+ messages in thread
From: brian.inglis @ 2024-06-28 22:32 UTC (permalink / raw)
To: newlib
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
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2024-06-28 22:32 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-06-28 14:37 C11/POSIX-2024 Questions Joel Sherrill
2024-06-28 16:00 ` John Scott
2024-06-28 21:32 ` brian.inglis
2024-06-28 22:01 ` Joel Sherrill
2024-06-28 22:32 ` brian.inglis
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).