This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ 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: Some details on the named locale problem


On Mon, Jan 28, 2002 at 03:43:28PM -0800, Ulrich Drepper wrote:
> This is a problem with the C++ ABI.  In C, as mentioned, adding an
> empty string doesn't change anything.  Since the C++ interface is
> broken by design and requires a character you'll have to handle a NUL
> character special and, yes, probably set the grouping string to a
> value so that the code does not try to group anything.

Of course the C++ interface isn't broken.  (It's best not to pronounce 
judgment on things one knows nothing about.)

The C++ interface unsurprisingly specifies "no grouping" by an empty 
grouping() result.  The thousands_sep() value does not participate in 
the decision.  The thousands_sep() result is used only if grouping is 
specified.  This is simpler than the C approach.

In the C++ implementation it suffices to take the first character
from the string found, and if that's NUL, then so be it.  If the 
locale file specifies a non-empty grouping string, in that case, 
then somebody made a mistake writing it, because it's meaningless.

It would probably be a service to users to correct the locale 
author's error by invisibly by returning an empty string from 
grouping() in that case.  But the formatting code should handle 
inserting NUL separators without any special cases.
 
> ISO C uses an empty string to denote no thousands separator.

ISO C uses an empty string in either of two places (the separator
*or* the grouping) to indicate no grouping (and thus no thousands
separator) is to be applied.  It places the additional constraint
that the thousands_sep string must be only one character.  (It's
a string and not a char in order to permit a vendor extension of
allowing a multibyte separator, not that anyone does that.)

Of course the C library never actually uses any of this stuff, so
it doesn't really matter what they contain.  Since it rarely matters,
they frequently contain nonsense, which is (in turn) why user programs 
can't generally use them either.

Nathan Myers
ncm at cantrip dot org


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