Re: Public disclosure of discovered vulnerabilities

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

Date: Wed, 25 May 2005 23:44:46 GMT

Douglas A. Gwyn wrote:
> Bryan Olson wrote:
>
>> ... Similarly, Gwyn was wrong when he wrote:
>> The toupper function has an int argument, not char, and it
>> is perfectly safe to feed it any character code (or EOF).
>>
>> According to the standard, that is false. Character codes may be
>> negative, and toupper() yields undefined behavior for any such
>> code that doesn't happen to equal EOF.
>
> I am unaware of any character encoding scheme
> in actual use that employs negative values;

Obviously you were unaware. Your unawareness, whether of
character codes or of the C standard, is obviously what lead you
say that certain C programming practices are "perfectly safe",
when in fact they can induce undefined behavior.

Ever heard of the IBM PC? It's native character set, still in
use, includes codes that are negative in some C implementations.
(It has smilies and playing-card-suits and crap.) I cannot
attest that those implementations are entirely standard-
conferment, but their use of negative character codes is legal
under the standard. That stuff in the C standard about "basic
character set" and "extended character set": do you have any
idea what it means?

But more to the point, is honesty too much to ask? Since when
has your position been that C code is fine as long as it
survives in the well-known implementations, even if it induces
undefined behavior according to the standard?

> toupper works fine when used with actual
> character codes.

Warning: Do not believe Gwyn. Following his guidance in this
case can result in code with undefined behavior under the C
standard.

> If you're going to play
> around with negative codes you had better know
> what you're doing and take the steps necessary
> for your oddball computation to work. There
> is no reason that the standard library should
> be bogged down with extra masks and/or range
> checks that aren't needed in the vast majority
> of cases, when they can easily be added by the
> occasional program that needs them. If you
> want a slow PL, there are plenty to choose from.

In the future, when you imply that only incompetent programmers
produce or accept C code with undefined behavior, you will
remember that you in that group? Right? 

-- 
--Bryan

Relevant Pages

  • Re: CDT-5
    ... The codes come out every two years right now. ... A good PMS is far too important a part of a dental practice. ... > That's one of the reasons I quit the ADA. ... >> this standard, but charges us to obtain a copy of the standard once ...
    (sci.med.dentistry)
  • Re: on buffer overflows and insecurity
    ... Clearly the standard cannot specify codes for all ... possible errors in all possible implementations. ... such as requiring more functions to set ...
    (comp.lang.c)
  • Re: CDT-5
    ... I have no problem with new codes coming out every couple of years to improve ... the definition of what we do and standardizing how we bill insurance ... Anyone beside me annoyed that the ADA uses our dues money to ... >> this standard, but charges us to obtain a copy of the standard once ...
    (sci.med.dentistry)
  • Re: on buffer overflows and insecurity
    ... Clearly the standard cannot specify codes for all ... is specify that there are codes for the commonest errors. ... Exxx values have no hierarchy or other structure, ...
    (comp.lang.c)
  • Re: Public disclosure of discovered vulnerabilities
    ... Really I wonder if the standard even ... >> says character codes have to be integers. ... > references to a particular ANSI DP dictionary; ... ISO I think you are looking for 30301, ...
    (sci.crypt)