This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of NAD status.
Section: 28.3.3.1 [locale] Status: NAD Submitter: Martin Sebor Opened: 2001-07-15 Last modified: 2016-01-28
Priority: Not Prioritized
View all other issues in [locale].
View all issues with NAD status.
Discussion:
The "exposition only" value of the std::locale::none constant shown in the definition of class locale is misleading in that it on many systems conflicts with the value assigned to one if the LC_XXX constants (specifically, LC_COLLATE on AIX, LC_ALL on HP-UX, LC_CTYPE on Linux and SunOS). This causes incorrect behavior when such a constant is passed to one of the locale member functions that accept a locale::category argument and interpret it as either the C LC_XXX constant or a bitmap of locale::category values. At least three major implementations adopt the suggested value without a change and consequently suffer from this problem.
For instance, the following code will (presumably) incorrectly copy facets belonging to the collate category from the German locale on AIX:
std::locale l (std::locale ("C"), "de_DE", std::locale::none);
Rationale:
The LWG agrees that it may be difficult to implement locale member
functions in such a way that they can take either category
arguments or the LC_ constants defined in <cctype>. In light of
this requirement (28.3.3.1.2.1 [locale.category], paragraph 2), and in light
of the requirement in the preceding paragraph that it is possible to
combine category bitmask elements with bitwise operations,
defining the category elements is delicate,
particularly if an implementor is constrained to work with a
preexisting C library. (Just using the existing LC_ constants would
not work in general.) There's no set of "exposition only" values that
could give library implementors proper guidance in such a delicate
matter. The non-normative example we're giving is no worse than
any other choice would be.