This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] PR18785: Support non-native execution charsets
- From: Roger Sayle <roger at eyesopen dot com>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Wed, 22 Dec 2004 12:31:21 -0700 (MST)
- Subject: Re: [PATCH] PR18785: Support non-native execution charsets
On Wed, 22 Dec 2004, Joseph S. Myers wrote:
> > which when compiled on Linux with mainline CVS, using the command line
> > gcc -c -Wall -fexec-charset=IBM1047 warn.c
> > generates the inappropriate/incorrect diagnostics:
> > warn.c: In function `foo':
> > warn.c:5: warning: spurious trailing `%' in format
> > warn.c:5: warning: too many arguments for format
> There would seem to be something wrong with the testing if you get "`"
> from mainline as a left quote.
> I don't actually see why this patch would affect format diagnostics since
> they don't use c_getstr. But if it does, I think that would be losing
> diagnostics for the common case of -fexec-charset to avoid wrong ones for
> the uncommon case.
My mistakes; I pasted the above warnings from the wrong window. I did
confirm that exactly the same diagnostics (modulo the `) are still
generated by mainline. I've also checked and confirmed that the
Wformat diagnostic machinery doesn't use c_getstr, so my patch doesn't
fix the above failure, but does provide the necessary infrastructure
to correct it.
Rather than file an new PR for it, I'm currently bootstrapping and
regression testing a variant of my patch that does fix this bug.
> 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.
> What I do object to is the c_getstr change, which is far more wide-ranging
> than necessary in its disabling of optimizations. The disabling should be
> done locally in expand_builtin_printf, expand_builtin_fprintf,
> expand_builtin_sprintf, fold_builtin_sprintf which need it. In addition I
> see that __builtin_nan could be a problem, but is harder to deal with.
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
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.
Or perhaps, perversely, we disable use of c_getstr with -ffree-standing?