jacob navia said:
The deeper problem is that the C users community doesn't even want
to a knowledge this problem.
A buffer overrun is *specified* in the code of the C standard
itself. The many discussions in this group or in the similar group
comp.lang.c have led to nothing. Endless discussions about trivia but
an enormous BUG specified in the C standard (the asctime() function)
will be conserved as it was the best thing to do.
The code of the asctime() function is written in the C standard as follows:
char *asctime(const struct tm *timeptr)
{ [snip]
}
This code will provoke a buffer overflow if the year is, for
instance, bigger than 8099. Nowhere in the standard are the ranges
for the year are specified.
Then how do you know that the limit is 8099?
The range for tm_year is not specified explicitly, and I agree that it
would be helpful if it were. But the range is rigorously specified by
the code provided in the standard. You and I were able to figure it
out.
Consider:
char s[5];
strcpy(s, "hello, world");
Is this a bug in strcpy, or a bug in the code that uses it?
Stealing from Tom St Denis's followup:
struct tm t;
char *p;
memset(&t, 0, sizeof t);
t.tm_year = 10000;
p = asctime(&t);
Is this a bug in asctime, or a bug in the code that uses it?
If your answers are different, can you explain the difference?
Let me be clear. I don't like asctime(). I never use it, other than
in small programs intended to test the functionality of asctime()
itself. I personally think it should be deprecated. But the fact
that its behavior is undefined *given certain arguments* is something
it shares with most other functions in the standard library. And
(the following is just my opinion), given that it's already rigorously
specified, I don't think it would be worth the committee's time to
improve the specification or change the behavior. Why sharpen the
corners on a square wheel?
If you're an implementer, you can provide an asctime() implementation
that doesn't blow up unless you give it a bad pointer (glibc has
done this; I presume you have as well, though I wonder whether yours
is 100% conforming in the corner cases). If you're a programmer,
you can avoid calling asctime() with exotic argument values, or
you can avoid calling asctime() altogether and use the much more
flexible strftime() instead.
Has there been an epidemic of crashing software caused by bad calls
to asctime()? The worst I've seen is a few extraneous newlines in
log files, which had nothing to do with undefined behavior.
It's just not as big a problem as you repeatedly make it out to be.
Ok, if there were a bug in the standard, a clause that implicitly
requires a buffer overflow to occur, that would be a problem worth
fixing, even if it didn't have much effect on the real world.
But that's just not the case here. (It is for gets(), which is
being deprecated, and I'd also be happier if that had been done
sooner or at a quicker pace.)
[...]
Is it because most people have decided that C should be killed and C++
should be the language of choice?
Of course not, don't be silly. Do you seriously think that someone
who has decided C should be killed would spend time and money
serving on the C standard committee? You're really not very good
at inferring other people's motivations.
Probably, I can't tell.
The same for any evolution of the language. The proposed new C
standard to be released somewhen in 2019 or later is a textual copy
of the C99 one, including (of course) functions like gets() and
asctime(). The only "concession" of the committee has been to add a
footnote where it says that gets() is deprecated.
The proposed new standard is a work in progress. We don't know
how closely it will match the early drafts that have been released
so far. In particular, the changes that have been made so far
are probably not representative of the changes that will be made;
they're just what the committee got to first, and I don't think
they're doing the work in decreasing order of importance.
[A personal note: jacob, I recently sent you a private e-mail message
regarding something you wrote in another thread. I would appreciate
a response, either by e-mail or as a followup in the relevant thread.
Thank you.]