[PATCH] Fix initialization of _M_grouping

[Paolo Carlini]

Nathan Myers wrote:

> Hi all,
>
> My apologies for the delay in replying.  I claim a 3.74 kg (8lb 4oz)
> EXCUSE, as of 5:07 this morning.  His mother begs your indulgence.

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!Greetings, Nathan!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

> I don't think I understand your example properly.
> So, just to be clear, this is what I think should pass:
>
> #include <locale>
> #include <sstream>
> #include <streambuf>
>
> struct testpunct : std::numpunct<char>
> {
>   //  char do_thousands_sep() const { return '0'; }
>   char do_thousands_sep() const { return '\0'; }
>   std::string do_grouping() const { return std::string("\002"); }
> };
>
> int main()
> {
>   // "1\00023\00045"
>   char s[] = { '1', '\0', '2', '3', '\0', '4', '5' };
>   const std::string str(s, 7);
>   std::stringstream ss(str);
>   ss.rdbuf()->pubseekoff(0, ss.beg);
>
>   const std::locale loc(std::locale::classic(), new testpunct);
>   ss.imbue(loc);
>
>   long l;
>   ss >> l;
>   assert(l == 12345);
>   return 0;
> }

Indeed, it passes!!
I was just debugging the original testcase posted by Benjamin, and it appeared
clear that the parsing code was parsing the \000 embedded in the string literal
as on single block, the separator indeed, thus leading to an error eventually
for grouping == "\004". Thanks for the clarification!!

> In other words, in C++ the NUL character has no more significance than
> any other non-whitespace control character, except where C strings are
> presented in an interface.  Any internal operations that treat NUL
> differently result in bugs.

I see.

Therefore, it looks like we don't have any other open issue here beyond the
pending __M_grouping inizialization to "" for named locales with
_M_thousands_sep = '\0', right?

Cheers,
Paolo.