From: kaih@khms.westfalen.de (Kai Henningsen)
To: gcc@gcc.gnu.org
Subject: Re: signed vs unsigned pointer warning
Date: Mon, 11 Oct 2004 00:11:00 -0000 [thread overview]
Message-ID: <9Ia4D$QXw-B@khms.westfalen.de> (raw)
In-Reply-To: <20041008173153.E89761422D56@darter.rentec.com>
terra@gnome.org (Morten Welinder) wrote on 08.10.04 in <20041008173153.E89761422D56@darter.rentec.com>:
> And regardless of the implementation's value of EOF, you cannot cast to
> "unsigned char" either because that would make EOF collide with one of
> the other 256 valid inputs.
The usual problem is that either you already have (implicitely) cast to
char where you shouldn't gave (the classic while((c=getchar())!=EOF) bug),
or else you just have EOF-less data anyway but it's in char*.
In the first case, obviously the answer is to make c an int as it should
have been in the first place, so you can distinguish between EOF and
(unsigned char)255 - there's a reason getchar() returns all characters as
unsigned char values. Then no casting is needed for isXXX().
In the second case, there's nothing wrong with casting to unsigned char -
in fact, that is exactly what is necessary. You can, of course, do it by
accessing your data with an unsigned char * pointer instead. That's just a
question of what looks better to you.
And I should mention wint_t/wchar_t here just for completeness.
Really, the fundamental bug was when the first C standard failed to have
separate unit-of-storage and character types, and allowed the fundamental
character type to be signed (and forced it to always be one storage unit,
thus wchar_t). There's really no good reason for characters to have signs.
(There occasionally is, of course, for storage units.)
It's probably far too late to fix that, unfortunately.
Anyway, the facts of life are that we have character-handling interfaces
that insist on unsigned chars (getchar(), isXXX()), and we have others
that insist on unadorned chars (strXXX(), "..."). And thus, we need extra
intelligence to figure out where we should or should not warn about
signedness-of-char issues.
Let this be a lesson to language designers about how NOT to do it.
MfG Kai
next prev parent reply other threads:[~2004-10-10 16:32 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-22 16:43 Morten Welinder
2004-09-22 17:17 ` Paul Koning
2004-09-22 17:27 ` Morten Welinder
2004-09-22 17:49 ` Dave Korn
2004-09-22 17:20 ` Dave Korn
2004-09-23 1:31 ` Andreas Schwab
2004-09-23 12:29 ` Dave Korn
2004-09-23 18:57 ` Joe Buck
2004-09-23 19:38 ` Dave Korn
2004-09-27 2:04 ` Jamie Lokier
2004-10-08 13:29 ` Nick Ing-Simmons
2004-10-08 13:32 ` Dave Korn
2004-10-08 17:20 ` Joe Buck
2004-10-08 17:28 ` Paul Jarc
2004-10-08 17:59 ` Joe Buck
2004-10-08 18:15 ` Dave Korn
2004-10-08 18:22 ` Joe Buck
2004-10-08 18:24 ` Jamie Lokier
2004-10-08 19:57 ` Paul Jarc
2004-10-09 7:05 ` Jamie Lokier
2004-10-09 8:48 ` Paul Jarc
2004-10-11 16:34 ` Richard Earnshaw
2004-10-08 18:57 ` Morten Welinder
2004-10-08 20:59 ` Matthias B.
2004-10-08 22:34 ` Paul Koning
2004-10-10 2:03 ` Matthias B.
2004-10-09 1:39 ` Andreas Schwab
2004-10-11 0:11 ` Kai Henningsen [this message]
-- strict thread matches above, loose matches on Subject: below --
2004-09-21 20:52 Richard Henderson
2004-09-21 22:36 ` Linus Torvalds
2004-09-22 14:35 ` Dave Korn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='9Ia4D$QXw-B@khms.westfalen.de' \
--to=kaih@khms.westfalen.de \
--cc=gcc@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).