* 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).