On 10/08/2014 02:27 AM, Walter Bright wrote:
On 10/7/2014 2:12 PM, Timon Gehr wrote:
On 10/07/2014 10:09 PM, Walter Bright wrote:
What defined behavior would you suggest would be possible after an
overflow bug is detected?
At the language level, there are many possibilities. Just look at what
type safe
languages do. It is not true that this must lead to UB by a "definition"
commonly agreed upon by participants in this thread.
And even in a safe language, how would you know that a bug in the
runtime didn't lead to corruption which put your program into the
unknown state?
Your assertion
Which assertion? That there are languages that call themselves type safe?
rests on some assumptions:
1. the "safe" language doesn't have bugs in its proof or specification
So what? I can report these if present. That's not undefined behaviour,
it is a wrong specification or a bug in the automated proof checker.
(In my experience however, the developers might not actually acknowledge
that the specification violates type safety. UB in @safe code is a joke.
But I am diverting.)
Not specific to our situation where we get an overflow.
2. the "safe" language doesn't have bugs in its implementation
So what? I can report these if present. That's not undefined behaviour,
it is wrong behaviour.
Not specific to our situation where we get an overflow.
3. that it is knowable what caused a bug without ever having debugged it
Why would I need to assume this to make my point?
Not specific to our situation where we get an overflow
4. that program state couldn't have been corrupted due to hardware failures
Not specific to our situation where we detect the problem.
5. that it's possible to write a perfect system
You cannot disprove this one, and no, I am not assuming this, but it
would be extraordinarily silly to write into the official language
specification: "a program may do anything at any time, because a
conforming implementation might contain bugs".
Also: Not specific to our situation where we detect the problem.
all of which are false.
I.e.
Why "I.e."?
it is not possible to define the state of a program after it has
entered an unknown state that was defined to never happen.
By assuming your 5 postulates are false, and filling in the
justification for the "i.e." you left out, one will quickly reach the
conclusion that it is not possible to define the behaviour of a program
at all. Therefore, if we describe programs, our words are meaningless,
because this is not "possible". This seems to quickly become a great
example of the kind of black/white thinking you warned against in
another post in this thread. It has to be allowed to use idealised
language, otherwise you cannot say or think anything.
What is _undefined behaviour_ depends on the specification alone, and as
flawed and ambiguous as that specification may be, in practice it will
still be an invaluable tool for communication among language
users/developers.
Can we at least agree that Dicebot's request for having the behaviour of
inadvisable constructs defined such that an implementation cannot
randomly change behaviour and then have the developers close down the
corresponding bugzilla issue because it was the user's fault anyway is
not unreasonable by definition because the system will not reach a
perfect state anyway, and then retire this discussion?
