Getting action on your favorite D issues

[Timon Gehr]

On 06.06.20 21:30, Joseph Rushton Wakeling wrote:
> On Saturday, 6 June 2020 at 15:16:06 UTC, ag0aep6g wrote:
>> But Walter agrees with you: Using a void value shouldn't actually have 
>> undefined behavior; it should just be an arbitrary value. Which is why 
>> he has an open pull request to change the spec:
>> https://github.com/dlang/dlang.org/pull/2260
> 
> Reading that PR, one comment stood out:
> 
>> The fact that the compilers don't define the behavior doesn't make it 
>> undefined according to the language spec
> ...

You have to read it in context. The PR attempts to change accessing 
void-initialized memory from undefined behavior to 
implementation-defined behavior. (I don't see how that helps in any way, 
but that's what it does.)
I.e., compiler implementations would have to specify the behavior. 
Walter is saying that if they fail to do that, that would then be an 
error in the documentation of those compilers.

> Which makes me ask: what _does_ "undefined behaviour" mean according to 
> the D language spec?
> ...

Unfortunately it does not mean the behavior is not defined. It means the 
behavior is explicitly defined to be arbitrary. It's not very 
well-designed terminology, but D inherits it from C.

> I'm not sure that the spec actually gives a definition: it certainly (in 
> the Introduction) starts talking about things that _result_ in undefined 
> behaviour, without ever first saying what undefined behaviour is.

In practice, it means what the backend developers take it to mean. In 
practice, this means that they will develop code generation procedures 
that are correct under the assumption that the source program never 
triggers UB. If that assumption is violated, demons may fly out of your 
nose, or more likely, bad actors will be able to take control of your 
process by carefully crafting inputs that exploit memory corruption.

https://en.wikipedia.org/wiki/Undefined_behavior