Re: Some details on the named locale problem

[Nathan Myers <ncm-nospam at cantrip dot org>]

On Mon, Jan 28, 2002 at 01:18:33PM +0100, Paolo Carlini wrote:
> In that case (which is giving problems):
> thousands_sep() == \000
> grouping() == \377\377
> 
> grouping() seems to me anomalous: if I understand well some
> documentation I have, only the last number can be CHAR_MAX (indicating
> that there is no grouping anymore), *not* both.

Yes, that grouping is nothing but weird.

In the case where you get nonsense from the C library (or, more
preferably, from its tables), you can substitute something reasonable.

For the case of a null thousands_sep, you can return the base
class result (',').  If you get 0xff as the first character in 
the grouping, that is equivalent to the empty string.  "\003\003"
is equivalent to a single "\003", but it's fairly harmless.
(You might want to ignore all but the bottom 4 bits of each
grouping character, in use, in case some idiot user passes "3"
instead of "\003".)

For the long term it would be better to have our own code to read
locale files, instead of relying on the C library.  On POSIX systems
where you don't know the locale file format (or placement) you are
at least guaranteed to have a program that will extract them to a 
standard format, which you can then compile into your own preferred
format.  Thus, at "make install" you can generate optimal locale
files for C++ use alone.  On GNU systems we can just read the 
C library's locale files directly because we know their format.
 
Nathan Myers
ncm at cantrip dot org