wchar_t values

[Doug Gwyn]

In article <661 at taumet.com>, steve at taumet.com (Stephen Clamage) writes:
> This is the kind of attitude which annoys those in the world whose native
> language is not English.

Pardon me for pointing this out, but the issue has nothing to do with
English vs. other languages, even if some people choose to take it
that way.  The issue is, how does one guarantee portability of source
code for C programs.  One important aspect of that is the requirement
for a certain SUFFICIENT set of source code "characters", which need
not be taken from ANY human language (witness APL).  However, due to
the universal support for a certain set of characters on all modern
computer systems, that was selected as the minimum requirement.  The
conversion of trigraphs (expressed in this universal character set) to
internal code values for a handful of special characters that are not
universally supported is simply the minimum mapping necessary to
ensure source code portability among all standard-conforming sites.
The C standard definitely allows for use of additional native
characters in strings, comments, etc. (use in an identifier would
have to generate at least one diagnostic, but otherwise is permitted).
However, programs that make use of such extensions are clearly not
going to be portable.

If we had known how confused people would get over character set
issues, perhaps X3J11 would have used totally weird glyphs for the
members of the source character set represented by Courier font in
the standard.  Then EVERYone would be forced to understand the
external physical -to- internal source set mapping that is ALWAYS
applied as the first part of translation phase 1 by ALL conforming
implementations.  It happens that in most environments (apparently
not including some in Denmark), an implementation can perform that
mapping quite trivially, which is perhaps why many people don't
seem to appreciate that a mapping is nevertheless being applied.