This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: `newlocale ()' clarifications
Hi,
Roland McGrath <roland@redhat.com> writes:
> newlocale et al are specified in a draft to be part of future POSIX standards
> (http://www.opengroup.org/bookstore/catalog/c065.htm). The standard is
> based on the glibc features. If it fails to specify newlocale's behavior
> to match what glibc does, that is an unintended error in the specification.
> How does Darwin's newlocale behave differently than glibc's?
> Does it conform to the specification?
Thanks for the link.
Here are the differences I noticed for `newlocale ()'. Actually, the
two first differences relate to items left unspecified by OpenGroup's
draft:
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.
2. Darwin's manpage reads that "[if] BASE is `LC_GLOBAL_LOCALE', the
global locale is used." Conversely, glibc crashes if BASE if
`LC_GLOBAL_LOCALE'.
Both conform with the draft which reads: "The results are undefined
if the BASE argument is the special locale object
`LC_GLOBAL_LOCALE'."
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.
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.
Are there specific implementation details or other issues motivating the
choice made by the draft and glibc authors?
> 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.
Thanks,
Ludovic.
[0] http://people.redhat.com/drepper/tllocale.ps.gz
[1] http://developer.apple.com/documentation/Darwin/Reference/ManPages/man3/newlocale.3.html