This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] PR18785: Support non-native execution charsets

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      (personal mail) (CodeSourcery mail) (Bugzilla assignments and CCs)

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]