Re: thoughts on martin's proposed patch for GCC and UTF-8

[Paul Eggert <eggert at twinsun dot com>]

I thought of some drawbacks to #pragma LC_CTYPE "ja_JP.PCK"
(or to #locale LC_CTYPE "ja_JP.PCK", for that matter).

* If the program text is converted from one encoding to another, its
  #pragma will become incorrect.  This will make it a hassle to convert
  program text automatically (e.g. from Shift-JIS to UTF-8).

* Locale names aren't very portable.  E.g. Solaris uses "ja" for
  EUC-JIS whereas Unixware uses "ja_JP.EUC".

Perhaps it would be better for GCC to autodetect the character set and
encoding, much as Emacs already does.  GCC could even reuse the Emacs
code.  There would have to be a way to override the default (e.g. a
command-line option), but autodetection might be good enough in practice
so that overriding would be rarely needed.

   Date: Sat, 19 Dec 1998 06:12:48 -0700 (MST)
   From: Richard Stallman <rms@gnu.org>

   It is not a good idea to use #pragma for anything
   that affects the meaning of the program.

But all the pragmas required by draft C9x affect the meaning of the
program.  I think draft C9x's intent is that #pragma not affect the
meaning of the program ``much''.

For reference, here are the draft C9x pragmas and what they do.

	#pragma STDC FP_CONTRACT ON allows a floating-point expression to be
	``contracted'', i.e. evaluated as though it were an atomic operation,
	thereby omitting rounding errors.  (E.g. PowerPC multiply-add.)

	#pragma STDC FENV_ACCESS ON lets floating-point code test flags or run
	under non-default modes.

	#pragma STDC CX_LIMITED_RANGE ON lets the implementation evaluate
	complex multiply, divide, and absolute value efficiently without
	worrying about correct behavior because of undue overflow and
	underflow.

	The default state of these pragmas is implementation-defined.