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

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

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |diagnostic
                 CC|                            |manu at gcc dot gnu.org

--- Comment #8 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2012-04-17 22:23:06 UTC ---
So, what is it? Is this a bug or not?

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

[preston at bannister dot us]

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

Preston L Bannister <preston at bannister dot us> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |preston at bannister dot us

--- Comment #9 from Preston L Bannister <preston at bannister dot us> ---
(In reply to Hallvard B Furuseth from comment #7)
> > The warning in C++ is arguably bogus because the value of the
> > character '%' is known at compile-time, consequently the warning
> > is unwarranted (unless it really is negative).
> 
> unwarranted unless it _could_ be negative on some host.

Are there any hosts of this sort left? And for which GCC compiles?

The job of the compiler is to generate code for a specific machine. For a
character literal the compiler knows the exact value. If the value were
negative, a warning is justified. 

Generating a warning on code that is correct for the target is not useful. 

Likely the code will never be compiled on a platform where the warning is
correct.

Given almost no possibility the warning will ever be correctly identify a
problem, this is at least a very poor choice, and infinitely close to a bug. :)

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

[h dot b dot furuseth at usit dot uio dot no]

------- Comment #7 from h dot b dot furuseth at usit dot uio dot no  2006-10-24 08:20 -------
Subject: Re:  Issues with -Wchar-subscripts

gdr at integrable-solutions dot net writes:
> The absence of warning in C is OK -- literal characters have type int
> in C.

Yes, but see previous comments.

> The warning in C++ is arguably bogus because the value of the
> character '%' is known at compile-time, consequently the warning
> is unwarranted (unless it really is negative).

unwarranted unless it _could_ be negative on some host.


-- 


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

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

[gdr at integrable-solutions dot net]

------- Comment #6 from gdr at integrable-solutions dot net  2006-10-24 06:32 -------
Subject: Re:   New: Issues with -Wchar-subscripts

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

| [This is both a C and C++ bug report, not sure how to classify that.]
| 
| int a[256];
| int A(char c) { return a[c];      } // C and C++ warnings, OK.

OK.

| int D(void)   { return a['%'];    } // Spurious C++ warning, no C warning

The absence of warning in C is OK -- literal characters have type int
in C.  The warning in C++ is arguably bogus because the value of the
character '%' is known at compile-time, consequently the warning is
unwarranted (unless it really is negative).

-- Gaby


-- 


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

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

[h dot b dot furuseth at usit dot uio dot no]

------- Comment #5 from h dot b dot furuseth at usit dot uio dot no  2006-10-17 12:49 -------
Subject: Re:  Issues with -Wchar-subscripts

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.

How about a -Warray-bounds option, maybe in -Wall, which tries to
catch array[negative index] and (when the array length is known)
array[too large positive index]?  That will also catch array['\300']
when the program meets a host where char is signed.

It'll give false alarms for fake variable-length arrays, but those are
not common and can be replaced with the real thing now.  This, I mean:
  struct Foo { blah blah; char array[1]; };
  struct Foo *foo = malloc(sizeof(struct Foo) + strlen(str));
  strcpy(foo->array, str);


-- 


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

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

[pinskia at gmail dot com]

------- Comment #4 from pinskia at gmail dot com  2006-10-14 18:08 -------
Subject: Re:  Issues with -Wchar-subscripts

On Sat, 2006-10-14 at 17:52 +0000, h dot b dot furuseth at usit dot uio
dot no wrote:
> > 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.

But at this point, we are talking about C++ where 'a' is of type char.
I have to look at what the C++ standard says about this.

-- Pinski


-- 


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

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

[Andrew Pinski]

On Sat, 2006-10-14 at 17:52 +0000, h dot b dot furuseth at usit dot uio
dot no wrote:
> > 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.

But at this point, we are talking about C++ where 'a' is of type char.
I have to look at what the C++ standard says about this.

-- Pinski

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

[h dot b dot furuseth at usit dot uio dot no]

[-- 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

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

[h dot b dot furuseth at usit dot uio dot no]

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


-- 


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

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

[pinskia at gcc dot gnu dot org]

------- Comment #1 from pinskia at gcc dot gnu dot org  2006-10-13 16:54 -------
'a' in C is not of the type char but instead int so not warning there is
correct really. 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.

Anyways the above expliation should resolve what is the current behavior GCC
has with its warning.


-- 


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