Re: on buffer overflows and insecurity

On Mon, 24 Sep 2007 18:34:28 +0000, Richard Harter wrote:
On Mon, 24 Sep 2007 16:47:25 +0000 (UTC),
=?iso-2022-kr?q?=1B=24=29CHarald_van_D=0E=29=26=0Fk?=
<truedfx@xxxxxxxxx> wrote:
On Mon, 24 Sep 2007 16:34:06 +0000, Richard Harter wrote:
On Mon, 24 Sep 2007 10:48:00 -0400, Eric Sosman <Eric.Sosman@xxxxxxx>
wrote:
What happens on a system where fopen() can fail for
reasons POSIX doesn't enumerate? I have used a system where a file
specification could (optionally) include an account name and password;
the attempt to open could fail because of bad credentials. You might,
with a stretch, translate this to POSIX' EACCESS, but that's really
not how EACCESS is described.

[snip litany of possible differences]

The obvious thing to do is have a general error code in addition to
the ones imported from posix. The general code would cover all errors
not otherwise classified. Do you have a problem with that?

I do. If fopen can fail for other reasons than specified by POSIX, the
implementation should define additional error codes properly. There's no
point in using something like EIDUNNO, which tells you nothing more than
fopen's NULL return value, when an implementation-specific EBADCRED
could be defined just as easily. It would then make sure a decent
message can get printed by strerror. (As an aside, I don't see the
problem with EACCES for this specific error, but I do agree with some of
the other snipped examples.)

I don't quite understand your objection. What we are talking about are
the error codes (that should be) required by the standard.

And you're suggesting requiring something like EIDUNNO, while I'm saying
this should not be required or even standardised at all.

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.

Adding codes for all possible errors is up to the implementation.

That's what I would like to see required, and what I believe you stated
should not even be allowed: you stated "The general code would cover all
errors not otherwise classified." I took this to mean fopen would be
allowed to a) succeed, b) set errno to one of the imported error codes,
or c) set errno to a general error indicator. Missing is the possibility
to set errno to an implementation-defined error indicator, and with that
possibility, I personally don't see a use for a general error indicator.
If I misunderstood what you meant, then could you please clarify?

However that is necessarily non-portable.

They can be portably used with strerror, and that's enough to make them
useful. Would they cause any problems that you can see?
.

Relevant Pages

  • Re: on buffer overflows and insecurity
    ... reasons POSIX doesn't enumerate? ... implementation should define additional error codes properly. ... is specify that there are codes for the commonest errors. ...
    (comp.lang.c)
  • Re: How to avoid undesired default values?
    ... I may specify an integer or real number but forget to ... I am using "gfortran" to compile my codes. ... Controlling init checking by individual program units. ... If you knew enough to be able to use the extra features you would not need ...
    (comp.lang.fortran)
  • Re: How to avoid undesired default values?
    ... I may specify an integer or real number but forget to ... I am using "gfortran" to compile my codes. ... Controlling init checking by individual program units. ...
    (comp.lang.fortran)
  • Re: How to avoid undesired default values?
    ... I may specify an integer or real number but forget to ... I am using "gfortran" to compile my codes. ... Controlling init checking by individual program units. ...
    (comp.lang.fortran)
  • Re: POSIX siginfo
    ... David Xu wrote: ... > is not in POSIX standard, all are machine dependent magical values ... POSIX lists all these standard codes: ...
    (freebsd-arch)