Re: on buffer overflows and insecurity

jacob navia <jacob@xxxxxxxxxxxxxxxx> writes:
Eric Sosman wrote:
Richard Harter wrote On 09/24/07 14:34,:
[...]
I don't quite understand your objection. What we are talking
about are the error codes (that should be) required by the
standard. Clearly the standard cannot specify codes for all
possible errors in all possible implementations. What it can do
is specify that there are codes for the commonest errors.
... but then it would need to describe those commonest
errors in an unambiguous and system-independent way. Since
Exxx values have no hierarchy or other structure, fopen()
could produce ENOHOPE *or* EBADLUCK *or* some platform-
defined Exxx, but not a superposition of more than one.
If the Standard required that failures due to resource
exhaustion produce EALLGONE, it would thereby prevent the
implementation from using the more informative but platform-
specific ENOCHEESE.
It would be nice to raise the floor on QoI, but not at
the cost of instituting a ceiling.

Of course not, if we use just the lower 3 bits of errno
and leave the rest for the different implementations

Wouldn't that invalidate every existing implementation?

The errno mechanism has some serious problems. I'd like to see some
incremental improvements, such as requiring more functions to set
errno on failure, and *maybe* defining more standard codes than the
current EDOM, EILSEQ, and ERANGE. But any change that breaks existing
code is a non-starter, and any change that breaks existing
implementations will face a great deal of resistance; the payoff would
have to be better than anything I've seen proposed here.

Personally, I'd like to see an exception mechanism in C. Probably
something similar to what C++ has, but with some restrictions, would
have the best chance of being accepted. But before we can seriously
consider adding features to C, we have to deal with the current lack
of support for the current C standard; until C99 is supported, there's
not much point in adding major features to C200X or C201Y.

--
Keith Thompson (The_Other_Keith) kst-u@xxxxxxx <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
.

Relevant Pages

  • Re: RfD: IEEE-FP
    ... except as interchange formats as required by Standard ... > Control Field of the FPU control word is set to double and single as ... about requiring it in this specification. ... has a lot of implementations on IEEE-compatible hardware, ...
    (comp.lang.forth)
  • Re: on buffer overflows and insecurity
    ... Clearly the standard cannot specify codes for all ... possible errors in all possible implementations. ... Exxx values have no hierarchy or other structure, ...
    (comp.lang.c)
  • Re: FILE argument to a function
    ... justify requiring it for all implementations. ... FILE were a typedef for void, making FILE* equivalent to void*, the ... Does the standard require that implementations allow you to do ...
    (comp.lang.c)
  • Re: Succesful Status code
    ... status but the standard does not allow implementations to add codes ... is that IBM has extension that allows the ... This worked fine for the pre'02 Standard values, ...
    (comp.lang.cobol)
  • 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)