Re: Nmap uses ctype macros improperly

[Solar Designer <solar () openwall com>]

On Tue, Jul 28, 2009 at 05:23:05PM +0400, Solar Designer wrote:
> unsigned char _bitmasks[0x200];
> [...]
> #define _LOWER 11
> [...]
> #define islower(c) \
>       ((c) == EOF ? 0 : ((int)_bitmasks[((c) << 1) + (_LOWER >> 3)] & (1 << (_LOWER & 7))))
>
> If "c" turns out to be an unsigned char instead of an int, this will
> fail for values of "c" with the 8th bit set.

I was wrong.  "unsigned char" gets promoted to "unsigned int" in
arithmetic contexts such as the above.

OK, I must admit I can't think of a reasonable implementation that would
suffer when the argument to ctype macros is of type "unsigned char"
rather than "int".  Yet I still think that strictly speaking an
implementation is free to misbehave in such a case.

Alexander

_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://SecLists.Org