Re: Nmap uses ctype macros improperly

[Solar Designer <solar () openwall com>]

On Tue, Jul 28, 2009 at 09:00:52AM -0600, David Fifield wrote:
> I had just written a program to test it too. However I wasn't sure if it
> worked only because of some behavior of GCC, or because some standard
> requires it. I admit I don't know where to look for normative rules like
> this; can you by chance point me to a standards document that defines
> the arithmetic type promotion rule?

I'm no expert in this, but here are a few references I found quickly:

ftp://ftp.research.att.com/pub/c++std/WP/CD2/
http://www.cs.technion.ac.il/users/yechiel/CS/C++draft/
http://www.cs.technion.ac.il/users/yechiel/CS/C-draft/
http://std.dkuug.dk/JTC1/SC22/WG14/www/docs/n869/

This is "4.5 Integral promotions", page 59 in ISO-CPP-body.pdf from the
.../C++draft/ URL above.

http://www.open-std.org/jtc1/sc22/open/n2356/conv.html
(scroll down or search for "4.5  Integral promotions")

https://www.securecoding.cert.org/confluence/display/cplusplus/INT02-A.+Understand+integer+conversion+rules
http://www.cse.unsw.edu.au/~patrykz/TenDRA/tdfc/tdfc7.html#S33

According to this last reference, there's a difference between ISO C and
traditional C here.  The former will promote "unsigned char" to "int",
whereas the latter will promote it to "unsigned int".  Luckily, for my
specific example it would not matter.

http://www.keil.com/support/docs/1754.htm

The above is a C compiler that lets one turn integer promotions off.
Perhaps this is not a platform Nmap would ever be compiled for. ;-)

> There are other problems with how the ctype functions are used. Well,
> the only one I can think of now is in ncat/http.c, where they are used
> to classify characters in HTTP. They should really be classified based
> on the byte values defined in the HTTP standards, and not on whatever
> the local character set happens to be. (For example, RFC 2616 defines
> CTL, but there is no guarantee that is the same as the set defined by
> iscntrl, even ignoring locale.) Also, that file refers to the CR and LF
> bytes as '\r' and '\n', but it should use the literal values 0x0A and 0x0D.

This makes sense to me.  It is not always right to use the macros.

Alexander

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