From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23857 invoked by alias); 9 Jul 2010 04:26:33 -0000 Received: (qmail 23846 invoked by uid 22791); 9 Jul 2010 04:26:32 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00,TW_RJ,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from service1.sh.cvut.cz (HELO service1.sh.cvut.cz) (147.32.127.214) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 09 Jul 2010 04:26:23 +0000 Received: from localhost (localhost [127.0.0.1]) by service1.sh.cvut.cz (Postfix) with ESMTP id 62ABD1252F9; Fri, 9 Jul 2010 06:26:21 +0200 (CEST) X-Spam-Score: -100.273 Received: from service1.sh.cvut.cz ([127.0.0.1]) by localhost (service1.sh.cvut.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uu9yoFSQHRPf; Fri, 9 Jul 2010 06:26:18 +0200 (CEST) Received: from [10.0.0.1] (13.101.broadband5.iol.cz [88.100.101.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: v.haisman@sh.cvut.cz) by service1.sh.cvut.cz (Postfix) with ESMTP id BC8D81252EB; Fri, 9 Jul 2010 06:26:17 +0200 (CEST) Message-ID: <4C36A4E4.4070405@sh.cvut.cz> Date: Fri, 09 Jul 2010 04:57:00 -0000 From: =?UTF-8?B?VsOhY2xhdiBIYWlzbWFu?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 MIME-Version: 1.0 To: cygwin@cygwin.com Subject: Re: Interesting discovery in the C library that Cygwin uses References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Reply-To: cygwin@cygwin.com Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com X-SW-Source: 2010-07/txt/msg00227.txt.bz2 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Gregg Levine wrote, On 9.7.2010 1:34: > Hello! > I made this discovery whilst building the urjtag program from its SVN trunk: > make[3]: Entering directory `/usr/local/urjtag/urjtag/trunk/urjtag/src/tap' > CC tap.lo > CC register.lo > CC state.lo > CC chain.lo > CC detect.lo > detect.c: In function `find_record': > detect.c:89: warning: array subscript has type `char' > detect.c:96: warning: array subscript has type `char' > detect.c:107: warning: array subscript has type `char' > detect.c:125: warning: array subscript has type `char' > detect.c:134: warning: array subscript has type `char' > detect.c:150: warning: array subscript has type `char' > make[3]: *** [detect.lo] Error 1 > make[3]: Leaving directory `/usr/local/urjtag/urjtag/trunk/urjtag/src/tap' > make[2]: *** [all-recursive] Error 1 > make[2]: Leaving directory `/usr/local/urjtag/urjtag/trunk/urjtag/src' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/usr/local/urjtag/urjtag/trunk/urjtag' > make: *** [all] Error 2 > The fix, temporarily as it happens was to add to the configure script > this one: --disable-werror . The chap who suggested it also suggested > that I complain here. It was described as an isspace() has an issue, > I won't use the term he used. > > The code can be found at http://urjtag.sf.net as it happens. > > Basically the program supporter there wants the people here for Cygwin > to, ah, fix their C library. I'm not convinced that's necessary, but > which C library is used here? And what could be fixed? - From the ctype.h: /* These macros are intentionally written in a manner that will trigger a gcc -Wall warning if the user mistakenly passes a 'char' instead of an int containing an 'unsigned char'. Note that the sizeof will always be 1, which is what we want for mapping EOF to __ctype_ptr__[0]; the use of a raw index inside the sizeof triggers the gcc warning if __c was of type char, and sizeof masks side effects of the extra __c. Meanwhile, the real index to __ctype_ptr__+1 must be cast to int, since isalpha(0x100000001LL) must equal isalpha(1), rather than being an out-of-bounds reference on a 64-bit machine. */ #define __ctype_lookup(__c) ((__ctype_ptr__+sizeof(""[__c]))[(int)(__c)]) The interesting part: "These macros are intentionally written in a manner that will trigger a gcc -Wall warning if the user mistakenly passes a 'char' instead of an int containing an 'unsigned char'." And this is from SUSv3: "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." His code invokes undefined behaviour in case the char value is negative. The warning is a good thing. He IMHO needs to fix his code. - -- VH -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFMNqTjr2CghdezFMkRCOKcAKDAjf97aQkCOMnChHklmF1h0P777gCfSfCo 7iVQdH4YBv9uPhyW0xNfAZo= =smu3 -----END PGP SIGNATURE----- -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple