Re: Interesting discovery in the C library that Cygwin uses
Am 09.07.2010, 01:34 Uhr, schrieb Gregg Levine: (warnings about char subscripts) 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? The C library (newlib) is fine, it is actually helpful here by emitting warnings for actual program defects. The supporter should be sold a clue, in the form of a copy of IEEE Standard 1003.1 or a deep link to the opengroup.org website. The urjtag source however should be fixed. It abuses the ctype.h interfaces. Arguments to the tolower() and other to*() and isspace() and other is*() functions MUST be cast to unsigned char (unless they are already unsigned char). Background is that these functions need to support the usual 8bit character range plus the 257th character EOF (-1). So the is*() functions will have to use a wider type than char, and now sign extension matters. If you don't cast the input to unsigned char, an argument of 0xff will alias EOF although it is not the same, and 0x80...0xfe will lead to undefined behaviour, possibly even crashes. Note: the warning may be specific to Cygwin, but the underlying program will show on more systems with input outside ASCII. I recall that at least some versions of Solaris would misbehave if you passed non-ASCII characters (think umlauts or accented characters, or Asian/Cyrillic/other national scripts) to these ctype.h functions. There are probably more... -- Matthias Andree -- 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
Interesting discovery in the C library that Cygwin uses
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? - Gregg C Levine gregg.drw...@gmail.com This signature fought the Time Wars, time and again. -- 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
Re: Interesting discovery in the C library that Cygwin uses
-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(0x10001LL) 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
Re: Interesting discovery in the C library that Cygwin uses
On 2010-07-08 23:34Z, Gregg Levine wrote: 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' http://urjtag.svn.sourceforge.net/viewvc/urjtag/trunk/urjtag/src/tap/detect.c?annotate=1799 char *p; ... while (*p isspace (*p)) The problem is that 'char' can be signed, and a signed quantity can be negative. But values passed to ctype.h functions like isspace() have to be in the (nonnegative) range of an unsigned char (or be equal to EOF); otherwise, the behavior is undefined. Consider using unsigned char *p; instead of char *p; in the example above. Here's some discussion: https://www.securecoding.cert.org/confluence/display/seccode/STR37-C.+Arguments+to+character+handling+functions+must+be+representable+as+an+unsigned+char http://old.nabble.com/warnings-from-use-of-ctype.h-methods-td27865685.html -- 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
