public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c++/29455] New: Issues with -Wchar-subscripts
@ 2006-10-13 12:51 h dot b dot furuseth at usit dot uio dot no
2006-10-13 16:54 ` [Bug c++/29455] " pinskia at gcc dot gnu dot org
` (6 more replies)
0 siblings, 7 replies; 9+ messages in thread
From: h dot b dot furuseth at usit dot uio dot no @ 2006-10-13 12:51 UTC (permalink / raw)
To: gcc-bugs
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1815 bytes --]
[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.
int D(void) { return a['%']; } // Spurious C++ warning, no C warning
int B(void) { return a['å']; } // C++ warning, missing C warning
int C(void) { return a['\300']; } // C++ warning, missing C warning
So,
g++ -Wchar-subscripts warns "array subscript has type 'char'" about
arr['%'] even though the index is guaranteed positive. gcc does not.
OTOH, gcc does not warn about a['\300'] or a['å'] (8-bit a-ring), even
with -fsigned-char which ensures that the subscript is negative.
Note, arr['@'] COULD be a bug in the program with characters like @ which
are not in the basic execution character set: C99 5.2.1p3; I haven't got
the C++ standard. Only characters in that character set are guaranteed
to be positive: C99 6.2.5p3. If the program is intended to be portable
to other character sets, it is buggy. Even if gcc doesn't support a
machine with that charset - if anyone does these days:-) So it might
make sense to have a -Wchar-subscripts=2 warning which only assumes the
basic execution character set, not the current character set.
In preprocessor expressions I don't know if it should check the source
or execution character set, or both...
--
Summary: Issues with -Wchar-subscripts
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: h dot b dot furuseth at usit dot uio dot no
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29455
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug c++/29455] Issues with -Wchar-subscripts
2006-10-13 12:51 [Bug c++/29455] New: Issues with -Wchar-subscripts h dot b dot furuseth at usit dot uio dot no
@ 2006-10-13 16:54 ` pinskia at gcc dot gnu dot org
2006-10-14 17:06 ` h dot b dot furuseth at usit dot uio dot no
` (5 subsequent siblings)
6 siblings, 0 replies; 9+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2006-10-13 16:54 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug c++/29455] Issues with -Wchar-subscripts
2006-10-13 12:51 [Bug c++/29455] New: Issues with -Wchar-subscripts h dot b dot furuseth at usit dot uio dot no
2006-10-13 16:54 ` [Bug c++/29455] " pinskia at gcc dot gnu dot org
@ 2006-10-14 17:06 ` h dot b dot furuseth at usit dot uio dot no
2006-10-14 17:53 ` h dot b dot furuseth at usit dot uio dot no
` (4 subsequent siblings)
6 siblings, 0 replies; 9+ messages in thread
From: h dot b dot furuseth at usit dot uio dot no @ 2006-10-14 17:06 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug c++/29455] Issues with -Wchar-subscripts
2006-10-13 12:51 [Bug c++/29455] New: Issues with -Wchar-subscripts h dot b dot furuseth at usit dot uio dot no
2006-10-13 16:54 ` [Bug c++/29455] " pinskia at gcc dot gnu dot org
2006-10-14 17:06 ` h dot b dot furuseth at usit dot uio dot no
@ 2006-10-14 17:53 ` h dot b dot furuseth at usit dot uio dot no
2006-10-14 18:08 ` Andrew Pinski
2006-10-14 18:08 ` pinskia at gmail dot com
` (3 subsequent siblings)
6 siblings, 1 reply; 9+ messages in thread
From: h dot b dot furuseth at usit dot uio dot no @ 2006-10-14 17:53 UTC (permalink / raw)
To: gcc-bugs
[-- 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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Bug c++/29455] Issues with -Wchar-subscripts
2006-10-14 17:53 ` h dot b dot furuseth at usit dot uio dot no
@ 2006-10-14 18:08 ` Andrew Pinski
0 siblings, 0 replies; 9+ messages in thread
From: Andrew Pinski @ 2006-10-14 18:08 UTC (permalink / raw)
To: gcc-bugzilla; +Cc: gcc-bugs
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug c++/29455] Issues with -Wchar-subscripts
2006-10-13 12:51 [Bug c++/29455] New: Issues with -Wchar-subscripts h dot b dot furuseth at usit dot uio dot no
` (2 preceding siblings ...)
2006-10-14 17:53 ` h dot b dot furuseth at usit dot uio dot no
@ 2006-10-14 18:08 ` pinskia at gmail dot com
2006-10-17 12:49 ` h dot b dot furuseth at usit dot uio dot no
` (2 subsequent siblings)
6 siblings, 0 replies; 9+ messages in thread
From: pinskia at gmail dot com @ 2006-10-14 18:08 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug c++/29455] Issues with -Wchar-subscripts
2006-10-13 12:51 [Bug c++/29455] New: Issues with -Wchar-subscripts h dot b dot furuseth at usit dot uio dot no
` (3 preceding siblings ...)
2006-10-14 18:08 ` pinskia at gmail dot com
@ 2006-10-17 12:49 ` h dot b dot furuseth at usit dot uio dot no
2006-10-24 6:32 ` gdr at integrable-solutions dot net
2006-10-24 8:20 ` h dot b dot furuseth at usit dot uio dot no
6 siblings, 0 replies; 9+ messages in thread
From: h dot b dot furuseth at usit dot uio dot no @ 2006-10-17 12:49 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug c++/29455] Issues with -Wchar-subscripts
2006-10-13 12:51 [Bug c++/29455] New: Issues with -Wchar-subscripts h dot b dot furuseth at usit dot uio dot no
` (4 preceding siblings ...)
2006-10-17 12:49 ` h dot b dot furuseth at usit dot uio dot no
@ 2006-10-24 6:32 ` gdr at integrable-solutions dot net
2006-10-24 8:20 ` h dot b dot furuseth at usit dot uio dot no
6 siblings, 0 replies; 9+ messages in thread
From: gdr at integrable-solutions dot net @ 2006-10-24 6:32 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug c++/29455] Issues with -Wchar-subscripts
2006-10-13 12:51 [Bug c++/29455] New: Issues with -Wchar-subscripts h dot b dot furuseth at usit dot uio dot no
` (5 preceding siblings ...)
2006-10-24 6:32 ` gdr at integrable-solutions dot net
@ 2006-10-24 8:20 ` h dot b dot furuseth at usit dot uio dot no
6 siblings, 0 replies; 9+ messages in thread
From: h dot b dot furuseth at usit dot uio dot no @ 2006-10-24 8:20 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2006-10-24 8:20 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-10-13 12:51 [Bug c++/29455] New: Issues with -Wchar-subscripts h dot b dot furuseth at usit dot uio dot no
2006-10-13 16:54 ` [Bug c++/29455] " pinskia at gcc dot gnu dot org
2006-10-14 17:06 ` h dot b dot furuseth at usit dot uio dot no
2006-10-14 17:53 ` h dot b dot furuseth at usit dot uio dot no
2006-10-14 18:08 ` Andrew Pinski
2006-10-14 18:08 ` pinskia at gmail dot com
2006-10-17 12:49 ` h dot b dot furuseth at usit dot uio dot no
2006-10-24 6:32 ` gdr at integrable-solutions dot net
2006-10-24 8:20 ` h dot b dot furuseth at usit dot uio dot no
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).