public inbox for newlib@sourceware.org
 help / color / mirror / Atom feed
From: brian.inglis@systematicsw.ab.ca
To: newlib@sourceware.org
Subject: Re: C11/POSIX-2024 Questions
Date: Fri, 28 Jun 2024 16:32:21 -0600	[thread overview]
Message-ID: <e5c3acd0-4899-4217-aa4d-721592f9febe@systematicsw.ab.ca> (raw)
In-Reply-To: <CAF9ehCWuEtUBPPfU+5bqEVvEPZ9pDauhR7QOi=MtPRvBHas_0Q@mail.gmail.com>

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


      reply	other threads:[~2024-06-28 22:32 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-28 14:37 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 message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e5c3acd0-4899-4217-aa4d-721592f9febe@systematicsw.ab.ca \
    --to=brian.inglis@systematicsw.ab.ca \
    --cc=newlib@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).