Re: [RFC] 27_io/ios_manip_basefield.cc

[Paolo Carlini <pcarlini at unitus dot it>]

Benjamin Kosnik wrote:

>Great. I'd suggest looking at the message identified earlier, from the 
>library reflector. The grouping status of numbers with 0x, 0X, 0 seems to 
>be unclear. (Ie, it's unknown how to treat them.) There's supposed to be 
>a DR about this too, but it was never written.
>
>0x123,456
>      or
>0x,123,456
>
>0123,456
>      or
>0,123,456
>
Yes, I read that message from Howard Hinnant that you kindly pointed me to.
However, I had interpreted it as meaning that the status of 0x and 0X 
was quite clear, in fact, that is the *first* interpretation was preferred.

>I'm up for the second interpretation, which should be easier to 
>implement and doesn't special case any digits. In general, I think grouping 
>for hex numbers makes little sense. Can anybody think of a reason to do so?
>

Well, as far as implementation easiness is concerned, I have *ready* one 
corresponding to the *first* interpretation!
I can post it if you like. Turned our to be not so difficult: it 
suffices to write "by hand" 0x, 0X or 0 into __ws2, and then process the 
remaining part of __ws with __add_grouping as usual. No regression on 
i686-pc-linux-gnu.

OTHO, I have *no* idea which interpretation is the most correct from the 
point of view of standard conformance. Of course I will take your word 
for this.

A trickiness of the second interpretation is the following: if you 
happen to put the grouping char between 0 and x[X] you destroy the two 
char signature of the hex number, exploited later during the padding. 
What do you think about this?
 
Thanks,
Paolo.