------- Comment #8 from pcarlini at suse dot de 2008-01-11 03:59 ------- (In reply to comment #7) > What I'm saying is that if the C library says localeconv()->grouping is "\3\3" > the C++ numpunct::grouping() shouldn't say it's something else.
Why not? If we agree that when the thousand separator returned by the C library is NUL, then localeconv()->grouping **is meaningless**, garbage, uninitialized memory (I think we previously agreed about that), I don't see why people can expect that match. In particular, I don't see that because, in C++, due probably to a limitation in the standard, there is no separate boolean in numpunct to tell "no-grouping": I maintain that essentially the only meaningful way to espress "no-grouping" in C++, in the grouping() string, is leaving the string empty. I think my reading of the standard is pretty straightforward, I mentioned a specific section, there is also a note, saying how "3" would be interpreted. Note, I'm not interested in num_put, here, of course in principle you can store "somewhere" the values returned by the underlying C library and make num_put happy, I do not dispute that you can play one of tricks you mentioned, for that. What I'm saying is that, a numpunct conveying to its user the meaning "no-grouping" is a numpunct returning an empty string from grouping(). Any other return value, even if for the sake of consistency of an hypothetical - note, I'm saying hypothetical, see above, I don't think localeconv()->grouping is anything but junk when the thousand separator is NUL, in C - localedata seems wrong to me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34733
