Re: Buffer overflows and asctime()
- From: Hallvard B Furuseth <h.b.furuseth@xxxxxxxxxxx>
- Date: Fri, 01 Aug 2008 17:12:58 +0200
jacob navia writes:
Jun Woong wrote:
Many have already pointed out that other standard functions have the
possibility for buffer overrun and asctime() should not be considered
to contain a "bug" as others are not.
The crucial difference is that those functions do not show
as sample code for their implementation code
You know perfectly well that most posters disagree with you about how
crucial that is and what that implies. You also know that most posters
agree it is a problem which should be addressed. If you'd quit
overstating the case, it might be possible to get on with discussing
_how_ to address it. Or maybe someone else could do that, anyway. I
think I've had enough.
that will overflow a buffer if given valid inputs!
And you also know that just about everyone disagrees with you about the
"valid inputs" part, and that the DR you originally quoted even does so
without reference to the standard's asctime code, and that it has been
suggested several times here to solve that problem by spelling it out
explicitly.
I wrote:
There is no UB when I pass a year of 15000 since the highest value
of the field is only (maybe) limited by the size of an int, and
should be able to contain values up to 32767 at least. Nowhere in the
standard the year member receives a maximum value.
You answer:
For asctime(), the standard implicitly says when the internal buffer
might overflow by providing the reference implementation written in
C.
This means that
(1) You find in the few lines of C in the C standard, code that
will overflow its buffer if confronted with valid inputs.
(2) Since the standard is always right this means that those
inputs are invalid.
So you actually do understand that reasoning. If you had refrained from
stuffing your "valid inputs" and "the standard is always right" strawmen
into the argument, you'd even be right.
Though it doesn't mean that's the only place you can see these inputs
are invalid. The DR you originally quoted does consider strange inputs
invalid anyway, after all. Unfortunately the standard doesn't say so.
Wait a minute, you make things too easy for the standard...
Instead of writing the limits of the year value somewhere
the standard "decides" to
(1) Never write those maximum values explicitly
(2) Define those limits by providing sample code that
will show UB if given certain inputs
Rubbish. The standard in effect does that, it doesn't "decide" to, and
quite possibly it was not deliberate. That is the problem a number of
posters _agree_ with you should be fixed, or at least that it is a valid
concern. Including the article you just replied to.
It looks like a BUG, it smells like a BUG, it tastes like a BUG
but it is a feature!
If you would refrain from overstating the case, that would be a
perfectly good complaint about _how_ the standard says this behavior
is undefined.
Whether it should say something else (like "unspecified behavior" or
returning NULL or whatever) is another issue. Why do you refuse to keep
that issue separate from claim that the above wording is a "BUG", even
when that is all someone is disagreeing with?
The sample code I proposed is 100% equivalent but it has noYour code is not 100% equivalent to C99's specification for
implicit buffer overflows in it.
asctime().
It can't be 100% equivalent since if it was, it would contain a buffer
overflow!
So you still do not understand "undefined behavior". The standard
explicitly says that it imposes no requirements on what the function
should do when there is undefined behavior, such as a buffer overflow.
If you eliminate the buffer overflow it is 100% equivalent to valid
inputs.
But not with all inputs, which means it is not 100% equivalent. Which
was the point. You claimed previously that it is 100% equivalent. Quit
making incorrect claims like that and then act as if people who point
out the error also are disagreeing with everything else you are saying.
(...)
What you do not understand is that I am NOT interested inYou can say that it is not a good idea to specify the semantic for a
fixing the possibility of a buffer overflow in some
implementations but in fixing the displayed code of that
function that is PLAIN WRONG in the C standard.
function by a reference implementation. You can say that an
implementation which simply copies the reference implementation in
the standard is poor. You can say that the design of the asctime()
function is not good so let's change it or at least mark it as
obsolete in the next revision. However, I don't think you can say
that the reference implementation is plain wrong unless you know what
the author's intent is. The author of that section might try to
codify existing implementations at that time and then decide the
reference code was a good and efficient way to do it.
I do not want to attack the person that wrote that code more
than 20 years ago. He was in ANOTHER environment, the internet
was an embryo, viruses and malicious code were absent etc!
It is not an attack on a person to say he got some code wrong anyway.
But it is obvious to all that he had a bug in his code because^^^^^^^^^^^
he did not consider years bigger than 10000. (After adding 1900)
What a beautiful illustration of why this discussion isn't getting
anywhere. Haven't you read anything of this thread? It's possible
everyone here disagree with you about exactly that. Fine. People who
disagree can still discuss and compare their opinions. But if you won't
even acknowledge others' opinions, then in is obviously impossible to
discuss and compare the merits of those different opinions.
In case you haven't noticed, a number of people think any problem is
with the specification of the function rather than in the code which
implements it. Such as not spelling out the valid arguments. People
disagree with you about whether it's OK for C standard functions to
allow undefined behavior for bad arguments. And about whether it makes
a "crucial" difference to those points that this particular function is
defined with code rather than words.
What I do not want is that the C standard continues to show that
code even when a DR was presented to the committee that pointed to
this bug.
It would have been nice if you discussed that instead then.
You keep calling the code presented in the standard a "bug." It can
be a bug only when it contains a behavior the author didn't intend, I
think. Are you really sure that it does?
Yes. Just let's be realistic.
"I will specify the ranges of the year not by writing
'The tm_year member should be between A and B'. NO. That
would be too simple. I will present a sample implementation
that will have UB when presented with a year greater than
9999, and this will define the ranges of years that
should be accepted. And I will decide that the correct
range is -2899 to 8099, that is obvious for anyone that
that range of years corresponds to an important period."
None of that is about whether the _code_ does what it intends, but
about its specification - that is, the standard's failure to spell
out when that code is supposed to have undefined behavior.
On the contrary the answer
to Clive Feather's DR implies that the given code is really what the
committee intended.
Actually no. It said there was no consensus to make a change, not that
it was consensus not to make a change. I don't know if that's
significant though. Maybe just a "form letter" phrase.
Thus, you'd better call your proposal "a change on the standard."
The answer to Clive Feather's bug report is not a bug, it
is worse than that. Anyone can have a bug. But refusing to
correct it is much WORSE.
I don't see how that is an argument against calling your proposal "a
change on the standard", or why you are arguing against that suggestion
in the first place.
--
Hallvard
.
- Follow-Ups:
- Re: Buffer overflows and asctime()
- From: lawrence . jones
- Re: Buffer overflows and asctime()
- References:
- Re: Buffer overflows and asctime()
- From: Jun Woong
- Re: Buffer overflows and asctime()
- From: jacob navia
- Re: Buffer overflows and asctime()
- Prev by Date: Re: Buffer overflows and asctime()
- Next by Date: Re: Buffer overflows and asctime()
- Previous by thread: Re: Buffer overflows and asctime()
- Next by thread: Re: Buffer overflows and asctime()
- Index(es):
Relevant Pages
|
