Date: Wed, 4 Oct 2000 00:09:50 -0400 (EDT) From: Thomas David Rivers <rivers@dignus.com> To: rivers@dignus.com, rnordier@nordier.com Cc: dnelson@emsphone.com, hackers@FreeBSD.ORG, lile@stdio.com Subject: Re: Question about -Wchar-subscripts Message-ID: <200010040409.AAA83630@lakes.dignus.com> In-Reply-To: <200010032127.XAA29173@c2-dbn-97.dial-up.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Robert Nordier <rnordier@nordier.com> wrote: > > Thomas David Rivers wrote: > > > > > So why is using a "char" as an array subscript wrong? I had always > > > > avoided it because the compiler complained and that was good enough > > > > for me. > > > > > > Because your char value could be negative and end up referencing memory > > > before your array start. Mainly a problem with the ctype macros and > > > high-ascii characters. > > > > > > > That's an interesting reason... any variable can be negative (well, > > except for the unsigned types...) - what's so interesting about > > `char'? Is it simply ctype macros that are the concern, or something > > "bigger"? > > What's interesting about char is that it's implementation defined > whether "plain" char is the equivalent of "signed char" or "unsigned > char" (or even something else). > > So, given an 8-bit, two's complement implementation of char, the > statement > > char i = 128; > > may cause 'i' to end up as -128 or 128, for example. > > An implementation-defined value to your subscript is almost never > useful, so this kind of behavior does warrant a warning. You'll > notice gcc doesn't warn if explicitly signed or unsigned chars are > used as subscripts, as then there is no uncertainty. > > -- > Robert Nordier Ah - yes! That makes perfect sense... when you consider that `char' all alone can be signed or unsigned... Thanks for the explanation! - Dave Rivers - To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200010040409.AAA83630>