From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1909 invoked by alias); 10 Oct 2004 16:32:34 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 1898 invoked from network); 10 Oct 2004 16:32:33 -0000 Received: from unknown (HELO colo.khms.westfalen.de) (213.239.196.208) by sourceware.org with SMTP; 10 Oct 2004 16:32:33 -0000 Received: from khms.vpn ([10.172.192.2]:47283 helo=khms.westfalen.de ident=Debian-exim) by colo.khms.westfalen.de with asmtp (TLS-1.0:RSA_ARCFOUR_SHA:16) (Exim 4.34) id 1CGgbN-0003RJ-UN for gcc@gcc.gnu.org; Sun, 10 Oct 2004 18:31:20 +0200 Received: from root (helo=khms.westfalen.de) by khms.westfalen.de with local-bsmtp (Exim 4.34) id 1CGgb1-0005fW-Pk for gcc@gcc.gnu.org; Sun, 10 Oct 2004 18:30:55 +0200 Received: by khms.westfalen.de (CrossPoint v3.12d.kh14 R/C435); 10 Oct 2004 18:01:35 +0200 Date: Mon, 11 Oct 2004 00:11:00 -0000 From: kaih@khms.westfalen.de (Kai Henningsen) To: gcc@gcc.gnu.org Message-ID: <9Ia4D$QXw-B@khms.westfalen.de> In-Reply-To: <20041008173153.E89761422D56@darter.rentec.com> Subject: Re: signed vs unsigned pointer warning MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Organization: Organisation? Me?! Are you kidding? References: <20040922161751.B4F6A1422D53@darter.rentec.com> <20041008130623.9516.4@llama.elixent.com> <20041008091714.A1695@synopsys.com> <20041008091714.A1695@synopsys.com> <20041008173153.E89761422D56@darter.rentec.com> X-No-Junk-Mail: I do not want to get *any* junk mail. Comment: Unsolicited commercial mail will incur an US$100 handling fee per received mail. X-Fix-Your-Modem: +++ATS2=255&WO1 X-SW-Source: 2004-10/txt/msg00395.txt.bz2 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