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.
Received on 2013-04-20 13:36:24 CEST