This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: `newlocale ()' clarifications


>  1. In glibc, if BASE is non-NULL, it is modified and the handle pointed
>     to by BASE is "not valid anymore" after a successful call [0].
>     Darwin's manual [1] simply reads that `newlocale ()' creates "a new
>     `locale_t' based off the locale specified by BASE."
> 
>     This is probably due to an omission is Darwin's manpage since
>     OpenGroup's draft agrees with glibc.

You can tell pretty easily if Darwin does behave differently, because it
will leak locale_t storage so a continuous loop of newlocale calls with
valid base locales will eventually fail from lack of memory.  Failing to
consume the base object is just incorrect, and if the specification doesn't
make that clear we should try to get it clarified.  That's why duplocale
exists, so you can copy a base locale to be consumed by newlocale.

>  3. Drepper's proposal [0] and the draft both say that, when BASE is
>     NULL, "the data for all sections not requested by CATEGORY_MASK
>     shall be taken from the default locale."  Here, "default locale"
>     really means "C locale" (at least, that's what glibc does).
> 
>     This contrasts with Darwin's manpage which reads: "If BASE is NULL,
>     the current locale is used."  This is not compatible with the draft
>     specs.

Indeed.  If the spec is not already unambiguous on what "default locale"
means, then we should make it so or make it use a clearer term in the
description of newlocale.

> I haven't tested all this on Darwin so I don't know whether the manpage
> really reflects what the implementation does or not.
> 
> For (3), I believe the approach taken by glibc/OpenGroup makes more
> sense than that of Darwin.
> 
> However, as far as (2) is concerned, I believe being able to use
> `LC_GLOBAL_LOCALE' as BASE is very useful.  Forbidding it makes it
> impossible to build a locale object deriving from the current locale.

I think you can use newlocale (LC_ALL_MASK, setlocale (LC_ALL, NULL), NULL).
I don't see why that wouldn't work, and portably.  That said, I don't
really see why newlocale couldn't treat LC_GLOBAL_LOCALE that way, but it
doesn't and it's stably been that way for quite some time now.

> Are there specific implementation details or other issues motivating the
> choice made by the draft and glibc authors?

I don't really recall.  

> > querylocale might be a worthwhile addition, but AFAIK no users have asked
> > for such functionality and noone proposed adding it to the standard.
> 
> FWIW, I do think that it would be a valuable addition.

Post a patch for glibc and you may get more active discussion about its worth.


Thanks,
Roland


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]