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

Relevant Pages

  • Re: Portability: Harmony between PC and microcontroller
    ... int is the natural integer type for the system. ... You are, perhaps unintentionally, paraphrasing the standard in a way ... One of the things that you might not realize is that the C programming ... In the real world, most embedded systems have more complex jobs to do, ...
    (comp.lang.c)
  • Re: Bit-fields and integral promotion
    ... > un/signed type knowledge. ... unsigned char, the int-sized object must be treated as signed. ... Admittedly it is unfortunate that the standard does not specifically ... int but an 8-bit unsigned bit field promoted to an unsigned int. ...
    (comp.lang.c)
  • Re: call of variadic function
    ... arguments that should be passed to this function are of type int. ... You call foo with more arguments than are ... which is the standard way to access arguments of a variadic function ... Here the else clause of my sentence specifies one of the numerous non- ...
    (comp.lang.c)
  • Re: pointer to const int
    ... int main ... ..and in fact the former causes undefined behavior. ... it's not an explicit requirement stated normatively in the standard ... terminating new-line character is implementation-defined. ...
    (comp.lang.c)
  • Re: K&R 2 exercise 2-3
    ... To be consistent with the standard library functions, ... to use int for character arguments. ... The stdout and stderr streams may be associated with different ...
    (comp.lang.c)