From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9923 invoked by alias); 22 Sep 2004 16:42: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 9912 invoked from network); 22 Sep 2004 16:42:44 -0000 Received: from unknown (HELO NUTMEG.CAM.ARTIMI.COM) (217.40.111.177) by sourceware.org with SMTP; 22 Sep 2004 16:42:44 -0000 Received: from mace ([192.168.1.25]) by NUTMEG.CAM.ARTIMI.COM with Microsoft SMTPSVC(6.0.3790.0); Wed, 22 Sep 2004 17:42:43 +0100 From: "Dave Korn" To: "'Morten Welinder'" , Subject: RE: signed vs unsigned pointer warning Date: Wed, 22 Sep 2004 17:20:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In-Reply-To: <20040922161751.B4F6A1422D53@darter.rentec.com> Message-ID: X-OriginalArrivalTime: 22 Sep 2004 16:42:43.0080 (UTC) FILETIME=[2E673880:01C4A0C3] X-SW-Source: 2004-09/txt/msg01291.txt.bz2 > -----Original Message----- > From: Morten Welinder [mailto:terra@gnome.org] > Sent: 22 September 2004 17:18 > Dave Korn writes: > > > Until you try indexing an array with an 8-bit high ASCII > char, of course. > > Then things become radically different. I've known buggy ctype > > implementations that have failed on this (ASCII > 127 being > signed negative > > and the ctype function accidentally indexing memory space > before an array > > full of ctype result flags). > > [/me gathers soapbox] > > I bet you have. In fact *ALL* ctype implementations will fail.[*] > That includes glibc You've provoked me to go and refer to the standard! http://www.opengroup.org/onlinepubs/009695399/functions/isprint.html ------------snip!------------ int isprint(int c); The c argument is an int, the value of which the application shall ensure is a character representable as an unsigned char or equal to the value of the macro EOF. If the argument has any other value, the behavior is undefined. ------------snip!------------ > It does not work for (signed char)-1 if EOF==-1. It cannot > work as two > different results are required for the same argument value. Um... but the ctype argument is an integer. If you pass EOF, you get (int)-1 in the ctype function. If you want to pass (signed char)-1, you have to ensure that -1 is "a character representable as an unsigned char" first. Which I don't think you can, since you can't store negative numbers in an unsigned type. So AFAICS, the valid range of inputs to the function is the closed range [-1,255] in integers. > What glibc does is to *mostly* work around buggy programs that send > (explicitly or implicitly) signed characters to, say, > isprint. The bug really is in passing a char to a function that requires an int argument and mismanaging the promotion by not explicitly casting the char first, isn't it? > Solaris does the array[arg] thing you speak about. It isn't > buggy. The caller is, and, IMHO the standard is. 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. 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. cheers, DaveK -- Can't think of a witty .sigline today....