[PATCH] Fix initialization of _M_grouping

[Nathan Myers]

On Mon, Jan 28, 2002 at 11:55:25PM +0100, Paolo Carlini wrote:
> this is the patch I have prepared, and already tested positively with
> libstdc++/5280 testcase. I'm currently retesting it with a new additional
> testcase. ...
>     _M_thousands_sep = *(__nl_langinfo_l(THOUSEP, __cloc));
> -   _M_grouping = __nl_langinfo_l(GROUPING, __cloc);
> +   // Check for NUL, which implies no grouping.
> +   if (_M_thousands_sep == '\0')
> +     _M_grouping = "";
> +   else
> +     _M_grouping = __nl_langinfo_l(GROUPING, __cloc);
>...
> -   _M_grouping = __nl_langinfo_l(GROUPING, __cloc);
> +   if (_M_thousands_sep == L'\0')
> +     _M_grouping = "";
> +   else
> +     _M_grouping = __nl_langinfo_l(GROUPING, __cloc);
>...
> +  VERIFY( th == '\0' );
> +  VERIFY( g == "" );

I'm having second thoughts about this.  It seems OK for the locale 
file to have an empty string, and for the C++ locale thousands_sep() 
to return a NUL.  It means that if a user derives from 
std::numpunct_byname<char>, and supplies a non-empty grouping, then 
num_put<> should just use the NUL as a group separator.  If they care, 
they should override both members.

Note that nonsense grouping strings might start with "\177" instead 
of "\377" on systems that have char signed, because it's the limits.h 
value CHAR_MAX that indicates it.  Maybe we should just ignore the 
high bit when checking for the no-repeat flag in num_put<>.

(For those of you who don't know C locale arcana, CHAR_MAX appearing 
in the format grouping string indicates that no more grouping should 
be applied.  E.g. "\2\177" (on some systems) or "\4\377" (on others) 
specifies a formatting like "12345678912345,6789".  With just "\4" 
you would get "12,3456,7891,2345,6789".)

Nathan Myers
ncm@cantrip.org