Re: Public disclosure of discovered vulnerabilities

From: Bryan Olson (fakeaddress_at_nowhere.org)
Date: 05/28/05 

Date: Sat, 28 May 2005 02:52:04 GMT

Douglas A. Gwyn wrote:
> Bryan Olson wrote:
>> ... You even said a certain practice
>> is "perfectly safe", when according to the standard it can
>> induce undefined behavior.
>
> You still don't understand what I said.

Well then, let's review. When I wrote:

     I passed an
     arbitrary char value to the C library's toupper() function.
     I had even looked it up in Harbison and Steele's highly-
     regarded /C, A Reference Manual/. Turned out the manual was
     wrong; passing an arbitrary value of type char to toupper()
     can cause a buffer overrun.

You replied:

     Olson has mischaracterized the issue, as usual. The toupper
     function has an int argument, not char, and it is perfectly
     safe to feed it any character code (or EOF). Olson's
     problem seems to be that he was unaware of the possibility
     of sign extension upon widening of a signed integer type,
     which might necessitate masking off the extension. Of
     *course* if you feed a wildly out-of-range value to toupper
     you get undefined behavior.

You said exactly what I said you said. You were wrong. No, it is
not perfectly safe to feed any character code to toupper().
According to the C standard, it can induce undefined behavior.

It is *not* true that sign extension from char to int can turn a
value "wildly out-of-range". In fact, the sign-extended value
will represent the same integer. You got it wrong.

I did not mischaracterize the issue. Harbison & Steele disagrees
with the C standard, as does what you asserted. I cited the
quotes -- I'll show it again upon request. I don't want to post
e-mail, but I assure you I was honest in reporting that Harbison
acknowledged the appearance of a error. Good guy. I tried to do
as much in admitting my incorrect C code. Too bad you are not of
that caliber.

As for your claim that I don't understand what you said, well,
there are things you said that baffle me; I've tried to be clear
on that. The sign-extension thing is so basic. How could you not
know that? And what you wrote after:

     The only way the C standard could have guaranteed well-
     defined behavior in the face of such abuse would have been
     to force the toupper function itself (and all the other
     <ctype.h> functions) to perform the masking

"The only way"? That's such utter C incompetence. To support all
char values, no extra masking is required, nor even helpful.

Please Doug, stop and think of the damage you might do by making
and standing by these false and deceptive claims. (And note that
until you admit the mistakes, I get to keep smugly citing them.) 

-- 
--Bryan

Relevant Pages

  • Re: Highly efficient string reversal code
    ... a char cannot have unused bits. ... Not in C99. ... In C99, if you read a trap representation, the ... code invokes undefined behavior. ...
    (comp.lang.c)
  • Re: pointer and storage
    ... I always thought that where the string literals are stored ... it invokes undefined behavior. ... pointer is unconditionally bad, ... "hello" is not const char *. ...
    (comp.lang.c)
  • Re: strchr const issue
    ... It's ugly *and* undefined behavior as soon as the value of p. ... const char* object will be assigned a char* (which is not a compatible ... may have incompatible representations */ ... If the commitee intended for pointer types differing only in qualification ...
    (comp.std.c)
  • Re: Discoved bug in c runtime in VC++ using isalnum()
    ... int main(int c, char* args){ ... Neither resource said anything about undefined behavior; ... > Despite Microsoft's idiotic help files, ...
    (comp.programming)
  • Re: UDB and pointer increments and decrements
    ... if s points to the start of a string and e becomes less than s then e is ... not really pointing to defined char. ... That's all "undefined behavior" means. ... And, as has been mentioned elsethread, a compiler is ...
    (comp.lang.c)
Quantcast