Email List: Xaustin-group-futures-lX
[All Lists]

Bug in Work Item 1.2.2 newlocale

To: yyyyyyyy@xxxxxxxxxxxxx
Subject: Bug in Work Item 1.2.2 newlocale
From: yyyyyyyyyyyyyy@xxxxxxxxxxx
Date: Fri, 19 Nov 2004 10:22:06 GMT
Cc: yyyyyyyyyyyyyyyyyyyyyy@xxxxxxxxxxxxx
        Bug report from : Konrad Schwarz , Siemens AG


@ page 11 line 229 section newlocale objection 
{thread-local-locale-extensions-2}

Problem:

A)
The newlocale() interface performs two distinct operations: creation of a new 
locale_t and modification of an existing one.  This seems to be unnecessary 
overloading.

B)
There is no way of modifying a locale_t by selectively using fields from a 
given locale_t, only from a locale string.

C)
The uselocale() routine offers no way of obtaining the locale_t currently in 
use by the calling thread without changing it.

D)
There is no way of retrieving a struct lconv from a locale_t. (This may be 
deliberate, because of the dynamic nature of locale_t).

Action:

A)
Split this interface into two:

locale_t newlocale(int category_mask, const char *locale);
int chlocale(int category_mask, const char *locale, locale_t base);

The return value for chlocale() could either be 0/1 for failure/success or it 
could directly return an errno value (which I believe is supposed to be default 
for all new POSIX routines).

B)
Add an interface:

int modlocale(int category_mask, locale_t modifier, locale_t base);

C)
Modify uselocale() to look like

void uselocale(locale_t *new, locale_t *old)

If new is not 0, then the new locale is taken from new.
If old is not 0, then the old locale is stored in *old.

D)
If the omission of localeconv_l() was intentional, add this to the rationale. 
Otherwise, add a routine

strut lconv *locale_l(locale_t base);

with the caveat that the returned pointer is valid only as long as the 
underlying locale_t has not been freed.

<Prev in Thread] Current Thread [Next in Thread>
  • Bug in Work Item 1.2.2 newlocale, konrad.schwarz <=