two bugs in getlocalename_l

[Corinna Vinschen]

Hi Bruno,

On Mar 24 18:12, Corinna Vinschen via Cygwin wrote:
> On Mar 24 14:12, Bruno Haible via Cygwin wrote:
> > Hi,
> > 
> > It's good to see the addition of getlocalename_l from POSIX [1] in Cygwin 3.6.0.
> > 
> > [1] https://pubs.opengroup.org/onlinepubs/9799919799/functions/getlocalename_l.html
> > 
> > However, there are two bugs:
> > 
> > 
> >   - "If
> >      the value is LC_ALL or is not a supported locale category value (see
> >      <<setlocale>>), <<getlocalename_l>> shall fail."
> >     No, that's now how it is specified.
> >     <https://www.austingroupbugs.net/view.php?id=1220> specified it this
> >     way, but <https://www.austingroupbugs.net/view.php?id=1741> added the
> >     LC_ALL support.
> 
> Drat.  I implemented this prior to id=1741.  This is unfortunate.
> 
> Without LC_ALL, only a single per-thread buffer of size ENCODING_LEN+1
> was required to allow LC_GLOBAL_LOCALE.
> 
> With LC_ALL and with the extra requirement that only a call to
> getlocalename_l(LC_GLOBAL_LOCALE) overwrites the per-thread
> LC_GLOBAL_LOCALE string buffer, we now need 2 per-thread buffers 
> of size _LC_LAST * (ENCODING_LEN+1).
> 
> >   - "<<getlocalename_l>> is POSIX-1.2008 since Base Specification Issue 8"
> >     No, it was introduced in POSIX-1.2024.
> 
> Yeah, that was temporary because the nameof the new standard wasn't
> known at the time I added this.

I fixed the comment and the invalid return value when specifying
LC_GLOBAL_LOCALE, as well as adding LC_ALL handling per the POSIX
specs.

The changes will be in test release cygwin-3.7.0-0.14.ga0fe984953dd
and in 3.6.1.


Thanks,
Corinna