On Sat, Apr 20, 2013 at 12:54:45PM +0200, Mattias Engdegård wrote: > 20 apr 2013 kl. 12.27 skrev Stefan Sperling: > > >>W: f:\dd\vctools\crt_bld\self_x86\crt\src\isctype.c(68) : Assertion > >>failed: (unsigned)(c + 1) <= 256 > >>]]] > > > >Seems like a bogus check to me. Is there a notion of debug vs. release > >builds in Visual Studio, and if so, does this happen in release mode > >builds? > > Sorry about barging in like this, but isn't this just a case of > calling ctype functions/macros with a char argument, where char is > signed by default? It's prohibited by the standard, although glibc > is "nice" enough to allow values in the [-128, 255] range just > because this mistake is so common.
Ah, yes! That explains the check. Thanks. > Looking at apr_fnmatch.c, it indeed seems like that is what is going on. Yes, since fnmatch() takes const char * arguments. > >See http://pubs.opengroup.org/onlinepubs/9699919799/functions/tolower.html > >It doesn't say "fail if the value overflows". > > That is not how the C standard works. When a library call is used > with arguments for which its behaviour is not defined, this results > in undefined behaviour. I've refreshed my memory on signed/unsigned conversion rules (scary stuff). The critical bit seems to be this one: The tolower() and tolower_l() functions have as a domain a type int, the value of which is representable as an unsigned char or the value of EOF. So... should apr_fnmatch() perform a range check and not call tolower() and similar ctype functions on char values outside the range [0x0, 0x7f] to avoid problems where negative char values are converted to huge unsigned integers? Seems to be a good way of avoiding the issue since the C locale doesn't support printable characters outside the ASCII range anyway, and apr_fnmatch() is currently not equipped to deal with other locales.
