Re: Buffer overflows and asctime()

jacob navia <jacob@xxxxxxxxxx> writes:
[...]
Lawyers, judges, and in general people that work with
legalese tend to get lost in their word mazes and loose
completely the concept of JUSTICE.

Here, the technical knowledge that should be the basis of
a technical standard is lost in a maze of legalese
so thick that an enormous BUG will be just talked away
with "normal" but not mandatory
values, or "limits defined implicitly by the reference
implementation", etc etc.

I can't argue in your legalese terms Mr Kuyper. I just know
what is a BUG and how to fix it.

My proposed implementation is a fix.

(1) It defined unambiguously the allowed ranges for all
fields.
(2) It never overflows the length of the buffer.
(3) It doesn't define anything implicitely.
(4): All fields that overflow their limits will be
flagged as wrong in a clear fashion.

(5) It changes the behavior of asctime() in certain cases where that
behavior is now unambiguously defined.

Are you *really* incapable of understanding that simple point?

This isn't about "JUSTICE". It's about a function that's been defined
as it is now since 1989. It's about a generation of programmers who
have been given an unconditional assurance that it will behave as
specified. And it's about you jumping in and wanting to revoke that
assurance in certain (admittedly unusual) cases.

And oh, yes, it's about you ignoring most of the direct questions I've
asked you.

The "BUG" in asctime stands out only because it's defined in C. Every
other function in the standard is defined in English (even srand() and
rand(), for which the standard provides non-normative sample
implementations). Most of those functions exhibit undefined behavior
when called with certain arguments.

Consider this:

char target[3];
strcpy(target, "this string is too big");

This call to strcpy() invokes undefined behavior. The specific action
that causes the undefined behavior occurs somewhere inside strcpy();
if strcpy() is implemented in C, it's likely that an assignment
statement invokes UB by attempting to assign to a nonexistent element
of the target array.

Is this a bug (pardon me, an enormous BUG) in strcpy()?

Would your answer change if the standard's definition of strcpy() said
that it must be implemented "using the equivalent of the following
algorithm", followed by a C implementation of strcpy()?

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

Relevant Pages

  • Re: worst.c - foolishness
    ... My change merely replaces "undefined behavior upon calling ... > my bug is much subtler. ... > will store a number in 'foo', and then, assuming the user has pressed ... I don't like the doublecheck for eof though. ...
    (comp.lang.c)
  • Re: lcc-win32
    ... > timeptr produce undefined behavior in the sample algorithm (for ... > I think that this was the wrong answer to give to a bug report. ... If you wish you can write a supervisory function to do the error ...
    (comp.lang.c)
  • Re: worst.c - foolishness
    ... Note the subtle change ... it's one bug less if you ignore the misdefinition.. ... elsewhere) with "undefined behavior upon passing NULL to feof". ... will store a number in 'foo', and then, assuming the user has pressed ...
    (comp.lang.c)
  • Re: sysv_ipc.c broken in v1.30 (was Re: sysvshm appearse broken in -current)
    ... Previously, we implemented that undefined behavior by accident: we appear to be improperly checking for access, but due to the flexibility of the checks, we grant them. ... We need to now implement the undefined behavior on purpose, since the new access control implementation is structured. ... A bug in the new ipcpermmay well be triggering the appearance of the error, but it appears also to be a product of incorrectly structured code in the existing shared memory implementation. ... We grant only valid rights, ...
    (freebsd-current)