From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13185 invoked by alias); 26 Sep 2004 19:21:45 -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 13177 invoked from network); 26 Sep 2004 19:21:43 -0000 Received: from unknown (HELO mail.shareable.org) (81.29.64.88) by sourceware.org with SMTP; 26 Sep 2004 19:21:43 -0000 Received: from mail.shareable.org (localhost [127.0.0.1]) by mail.shareable.org (8.12.8/8.12.8) with ESMTP id i8QJLg81030126; Sun, 26 Sep 2004 20:21:42 +0100 Received: (from jamie@localhost) by mail.shareable.org (8.12.8/8.12.8/Submit) id i8QJLgaC030124; Sun, 26 Sep 2004 20:21:42 +0100 Date: Mon, 27 Sep 2004 02:04:00 -0000 From: Jamie Lokier To: Dave Korn Cc: "'Morten Welinder'" , gcc@gcc.gnu.org Subject: Re: signed vs unsigned pointer warning Message-ID: <20040926192142.GA29842@mail.shareable.org> References: <20040922161751.B4F6A1422D53@darter.rentec.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-SW-Source: 2004-09/txt/msg01511.txt.bz2 Dave Korn wrote: > As I said, I think the standard makes it quite clear that you can pass -1 > and any unsigned char (0....255) value. It seems to me to say quite clearly > that if you have a signed char variable which is negative and you pass it to > the ctype function and allow it to be sign-extended by the implicit argument > promotion rules then you have supplied an out-of-range value to the > function. This is a real typical bug. Just recently a bug was found in curl-library, quite a popular little library, which calls isspace(char). The bug was missed for a long time, as it is only triggered with characters with the MSB set, which do not occur often in HTTP headers. Their fix was to change the program to use "unsigned char" strings, rather than change all the callers of isspace() as the latter change might not be preserved by future programmers who don't know why the cast in "issspace((unsigned char) c)" is necessary. I must admit that I hadn't realised it was necessary and I have written a lot of C (but I never use the is* functions anyway, so it's never arisen for me). I suspect quite a lot of programmers write "isspace(c)" and "isalnum(c)" et al using a "char" argument, not realising they have sometimes written buggy code - and it passes testing in many cases. This is a reason why GCC should issue a signedness warning. > Anyway, I only gave this particular example as an illustration to back up > my argument that the incompatibility between signed and unsigned chars is > not theoretical but very very real and does very much occur in practice as > it is very very common for char-sized arguments to be promoted to int sized > and the two types behave significantly differently when this happens. > That's all. I agree with you, except that the real practical problems arise from promotion to wider types, not operations involving just chars of various signedness. I agree with Linus that it's common to mix "char" with "unsigned char" in real code, and warning about calling strlen(unsigned char) would be too much. The balance where the warning is useful is that it should warn about errors such as calling "isspace()" with "char" or "signed char", but _not_ warn about calling "strlen()" and "memcpy()" with "unsigned char", or assigning a string constant to an "unsigned char *". -- Jamie