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


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


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