Re: Public disclosure of discovered vulnerabilities

From: Mike Amling (nospam_at_nospam.com)
Date: 05/25/05


Date: Wed, 25 May 2005 13:03:19 GMT

John E. Hadstate wrote:
> "Bryan Olson" <fakeaddress@nowhere.org> wrote in message
> news:pOPke.1265$rY6.1066@newssvr13.news.prodigy.com...
>
>>I was therefore quite surprised
>>when "infobahn" pointed out that the standard [ISO/IEC
>>9899:1999] reads:
>>
>> 7.4 (ctype.h)
>>
>> The header <ctype.h> declares several functions useful
>>for
>> classifying and mapping characters.166) In all cases
>>the
>> argument is an int, the value of which shall be
>> representable as an unsigned char or shall equal the
>>value
>> of the macro EOF. If the argument has any other value,
>>the
>> behavior is undefined.
>>
>
>
> That seems pretty clear to me. It seems to me that your
> beef is with the way some particular implementation defines
> behavior that the C standard doesn't.
>
> The C standard is riddled with "undefined behavior". One
> can argue until the cows come home (been there, done that)
> that a standard that canonizes "undefined behavior" is not a
> standard at all.

   "Undefined behavior" per se is not the problem. Explicitly stating
that something is undefined is much better than than just not saying
anything about it (a la Wirth's Pascal Manual and Report). System/360
had a lot of undefined behavior and was the stronger for it.
   Having said that, though, I have to say that the toupper() function
does not show defensive programming: It takes an int and if the int is
outside of some range, it may (apparently) fetch from ill-defined
storage. Someone is valuing speed over security.

--Mike Amling

--Mike Amling