This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] PR18785: Support non-native execution charsets
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Roger Sayle <roger at eyesopen dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Wed, 22 Dec 2004 21:14:57 +0000 (UTC)
- Subject: Re: [PATCH] PR18785: Support non-native execution charsets
- References: <Pine.LNX.email@example.com>
On Wed, 22 Dec 2004, Roger Sayle wrote:
> > If it does, there should be a testcase - but I think correcting it at
> > the expense of more valid messages would be wrong.
> The set of character sets supported by iconv is not portable from
> system to system, for example -fexec-charset=IBM1047 isn't supported
> on cygwin/newlib targets.
So tests use dg-require-iconv.
However I doubt that the work required to avoid losing the proper
diagnostics in what I consider the common case of -fexec-charset (all
character sets being supersets of ASCII) is appropriate at this stage.
> The API of c_getstr that returns a "const char*" is inappropriate for
> use with non-native character sets. Any uses of the current c_getstr
Only insofar as the target bytes might not be 8 bits. const char * works
fine as a datatype for an array of bytes as long as confusion between host
and target bytes doesn't matter, and as most of the str* and mem*
functions work as if on unsigned char the character set is irrelevant to
> that happen to work with -fexec-charset= are accidental and
> non-intentional. For example, the C99 standards statements over
> embedded NULs in target strings covers targets who's systems/runtimes
> are fully C99 compliant. Unfortunately, GCC is required to support
> many systems who aren't fully C99 compliant (Tru64, HPUX, Darwin,
> Windows, etc...) where the compiler can't/shouldn't make such assumptions
> about the execution environment.
Some DRs reflect bugs in the standard where the original version is not
meaningfully implementable. In such cases we don't attempt to implement
the uncorrected version for C90 mode even though C90 is no longer being
corrected through TCs. This is a case of a bug in the standard: NUL never
could be a second or subsequent byte of a multibyte character, and it
never was meaningfully possible to implement a runtime allowing it to be
the first byte of a multibyte character. So we simply do not support the
use of such character sets - and in fact I don't think any such character
sets could have been in use to be outlawed by C99 TC2.
> Or perhaps, perversely, we disable use of c_getstr with -ffree-standing?
-ffreestanding does imply -fno-builtin, but this is incidental and
__builtin_* can still be used.
Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/
firstname.lastname@example.org (personal mail)
email@example.com (CodeSourcery mail)
firstname.lastname@example.org (Bugzilla assignments and CCs)