This page is a snapshot from the LWG issues list, see theLibrary Active Issues List for more information and the meaning ofCD1 status.
Section: 28.3.4.3.2.3[facet.num.get.virtuals]Status:CD1Submitter: Matt AusternOpened: 2000-03-14Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [facet.num.get.virtuals].
View all otherissues in [facet.num.get.virtuals].
View all issues withCD1 status.
Discussion:
Stage 2 processing of numeric conversion is broken.
Table 55 in 22.2.2.1.2 says that when basefield is 0 the integralconversion specifier is %i. A %i specifier determines a number's baseby its prefix (0 for octal, 0x for hex), so the intention is clearlythat a 0x prefix is allowed. Paragraph 8 in the same section,however, describes very precisely how characters are processed. (Itmust be done "as if" by a specified code fragment.) Thatdescription does not allow a 0x prefix to be recognized.
Very roughly, stage 2 processing reads a char_type ct. It convertsct to a char, not by using narrow but by looking it up in atranslation table that was created by widening the string literal"0123456789abcdefABCDEF+-". The character "x" isnot found in that table, so it can't be recognized by stage 2processing.
Proposed resolution:
In 22.2.2.1.2 paragraph 8, replace the line:
static const char src[] = "0123456789abcdefABCDEF+-";
with the line:
static const char src[] = "0123456789abcdefxABCDEFX+-";
Rationale:
If we're using the technique of widening a string literal, thestring literal must contain every character we wish to recognize.This technique has the consequence that alternate representationsof digits will not be recognized. This design decision was madedeliberately, with full knowledge of that limitation.