[Bug c++/29455] Issues with -Wchar-subscripts

["h dot b dot furuseth at usit dot uio dot no" <gcc-bugzilla@gcc.gnu.org>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1700 bytes --]



------- Comment #3 from h dot b dot furuseth at usit dot uio dot no  2006-10-14 17:52 -------
Subject: Re:  Issues with -Wchar-subscripts

Sorry about the empty answer.

pinskia at gcc dot gnu dot org writes:
> 'a' in C is not of the type char but instead int so not warning there
> is correct really.

Hmm, yes, it fits the documentation.  I guess what I'm asking is for a
change in the warning's spec.  array['8-bit char'] is almost certainly
wrong in an iso646-derived charset, since for a portable program the
programmer can't know if the index is positive or negative.  I don't
know if enough information is available in C at the time the warning is
given do do that, though.

> Also you forgot one thing '%' does not have to match up with the ANSI
> character set so it could be negative in signed char which means char
> (which could default to signed char) would be different.

No.  In a conforming C implementation, the character *which C interprets
as '%'* must have a positive value.  Maybe you are thinking of the
opposite case:  What its glyph _looks like_ on some display device is out
of scope for the C standard.
In the 7-bit days we had screens with the Norwegian charset NS_4551-1,
but the C compiler (like most of the American-made computer) thought
it received ASCII.  Thus we had to write

   main() æ printf("Hello, world!Øn"); return 0; å

for the ASCII compiler to see

   main() { printf("Hello, world!\n"); return 0; }

The ANSI Rationale blessed this behavior since it already was
common (and more readable than trigraphs), the example there was
the Yen sign.  I can probably dig it up if you are interested.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29455