Re: on buffer overflows and insecurity

jacob navia wrote On 09/24/07 16:37,:
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

That's the kind of "structure" I alluded to earlier,
where part of the value summarizes an error and other parts
add detail. However, adding such structure to hitherto-
unstructured sets of errno values would be a *huge* job!
It would either change some existing Exxx values (forcing
recompilation of millions of modules) or introduce new ones
that supersede the old (forcing editing *and* recompilation
of millions of modules). The uptake rate of C99 has been
leisurely if not glacial, but compared to the uptake of a
C0x that began by breaking millions of valid programs ...

--
Eric.Sosman@xxxxxxx
.

Relevant Pages

  • 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: 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: Buffer overflows and asctime()
    ... struct tm members to be within their valid ranges is up to an user of ... There is no valid range for the year as specified in the standard. ... I wouldn't call it a defect, because the existence of a limit beyond which asctime() cannot be safely used is inferable from the description of asctime. ... I would consider it a substantial improvement for the standard to explicitly specify the limit. ...
    (comp.std.c)
  • 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: [fitsbits] Comments on image distortion conventions
    ... The document should specify default values for any coefficients that are absent from the header, but might be expected based upon the value of A_ORDER or B_ORDER. ... Presumably either the values would be taken to be zero or the convention should require that all keywords be present. ... The convention would appear to mis-use the CTYPEi reserved keyword in a way that at least technically violates the FITS standard. ... of including distortion in the pixel world coordinate transformation directly. ...
    (sci.astro.fits)