JTC1/SC22/WG14 N1119

Document: WG14 N1119
Date:	2005/04/08
---------------------------------------------------------------------------------

Defect report 279 stated:

Standard C requires ('x' == L'x') to hold true if x is a member of the
basic character set. This restricts the implementation's choice of wchar_t
encoding. The restriction makes it very difficult, if not impossible,
for EBCDIC based system to use Unicode as the wchar_t encoding.


The technical corrigendum (published in TC2) changed the following text:

     "...

       wchar_t

    which is an integer type whose range of values can represent distinct
    codes for all members of the largest extended character set specified
    among the supported locales; the null character shall have the code
    value zero and each member of the basic character set shall have a
    code value equal to its value when used as the lone character in an
    integer character constant."

TO

     "...

       wchar_t

    which is an integer type whose range of values can represent distinct
    codes for all members of the largest extended character set specified
    among the supported locales; the null character shall have the code
    value zero."

In other words, the text " and each member of the basic character set
shall have a code value equal to its value when used as the lone character
in an integer character constant" was deleted.

However, when the Austin Group considered making the equivalent change
many people complained that the removal of this promise would render may of
their applications non-ISO-C conforming, and if POSIX also made the change, they
would also be non-POSIX conforming (even though the applications would continue
to run on most architectures). In resolving this, the current proposal being considered
by the Austin Group is:

Change p317 line 11280 from:  
wchar_t     	Integer type whose range of values can represent distinct     
		wide-character codes for all members of the largest character set     
		specified among the locales supported by the compilation environment:     
		the null character has the code value 0 and each member of the     
		portable character set has a code value equal to
		its value when used as the lone character in an integer character
		constant."
to:  
wchar_t     	Integer type whose range of values can represent distinct     
		wide-character codes for all members of the largest character set     
		specified among the locales supported by the compilation environment;     
		the null character has the code value 0. Each member of the     
		portable character set has a code value equal to its value when used     
		as the lone character in an integer character constant if the
		implementation does not define __POSIX_NARROW_WCHAR__."
		
With appropriate shading of the added text. (to indicate that the shaded text is an
extension of the C stndard).

Add the following (appropriately shaded) text
after line 11288, new para:  
		The macro __POSIX_NARROW_WCHAR__, if defined
		by the implementation,  shall be defined as the integer constant 1.
		
Replace line 11292 with:  
		While the implementation may possibly define the macro
		__POSIX_NARROW_WCHAR__ in this header, it is considered preferable  that
		it be defined by the relevant C language implementation (that is,  the
		compiler or preprocessor).


================================

Question 1 :
Since this issue shows that the C TC2 is highly problematic for end users,
should it be revisited? The proposed wording, using __STDC_NARROW_WCHAR__ was one of
the committee's proposed solutions during the committee discussion.

Question 2: 
If POSIX makes this change, is this a permitted implementation defined extension to the standard?