On Saturday, 6 June 2020 at 13:08:06 UTC, ag0aep6g wrote:
> On 06.06.20 04:41, Walter Bright wrote:
>> You can already vote on Bugzilla issues.
>
> No you can't. The feature was disabled or removed at some point.

Yeah, though hopefully with the in-progress migration to GitHub issues voting will soon be possible again, see e.g. https://github.com/dlang/tools/issues/411

On Saturday, 6 June 2020 at 03:56:43 UTC, Timon Gehr wrote:
> On 06.06.20 05:40, Meta wrote:
>> 
>> The linked defect, and the issue you posted, don't really make sense to me. They both have UB; reading from an uninitialized variable (= void), or writing to one member of a union and reading from the other. Invoke Undefined Behaviour and you get... Undefined Behaviour.
>
> Right. It's in @safe code.

Ah, yes, I missed that. Why the hell is = void allowed in @safe again? I vaguely remember Walter arguing that it should be for some reason.

On Saturday, 6 June 2020 at 13:31:31 UTC, Meta wrote:
> On Saturday, 6 June 2020 at 03:56:43 UTC, Timon Gehr wrote:
>> On 06.06.20 05:40, Meta wrote:
>>> 
>>> The linked defect, and the issue you posted, don't really make sense to me. They both have UB; reading from an uninitialized variable (= void), or writing to one member of a union and reading from the other. Invoke Undefined Behaviour and you get... Undefined Behaviour.
>>
>> Right. It's in @safe code.
>
> Ah, yes, I missed that. Why the hell is = void allowed in @safe again? I vaguely remember Walter arguing that it should be for some reason.

Iirc it's only forbidden for pointers, because for other types garbage value != memory corruption. This is reflected in the recently updated spec section on "safe values" [1], which states:

> For basic data types, all possible bit patterns are safe.

It seems evident from this discussion that the above statement is not actually true, at least when it comes to bool.

[1] https://dlang.org/spec/function.html#safe-values

On Saturday, 6 June 2020 at 08:33:51 UTC, Stefan Koch wrote:
> On Friday, 5 June 2020 at 20:35:57 UTC, Walter Bright wrote:
>> [...]
>
> I have one that I really can't fix myself.
>
> The dwarf tag DW_TAG_inheritance which corresponds to the codeview's LF_BCLASS is missing.
> This inhibits debugging [for] executable[s] build by dmd. On linux.

bugzilla: https://issues.dlang.org/show_bug.cgi?id=20839
     and: https://issues.dlang.org/show_bug.cgi?id=15631

On 06.06.20 15:42, Paul Backus wrote:
> Iirc it's only forbidden for pointers, because for other types garbage value != memory corruption. This is reflected in the recently updated spec section on "safe values" [1], which states:
> 
>> For basic data types, all possible bit patterns are safe.
> 
> It seems evident from this discussion that the above statement is not actually true, at least when it comes to bool.
> 
> [1] https://dlang.org/spec/function.html#safe-values

I had thought about special-casing bool there, precisely because of the issue at hand. I almost wrote that only 0 and 1 are safe values for bool.

I decided against it, because it seems unlikely that creating values beyond 1 will be banned in @safe code. It seems more likely that the implementation gets changed to treat all non-zero values as true. At least that's what I extrapolate from Walter's position on void initialization in general (see <https://github.com/dlang/dlang.org/pull/2260/files>).

On Saturday, 6 June 2020 at 10:09:07 UTC, Patrick Schluter wrote:
> On Friday, 5 June 2020 at 23:53:28 UTC, H. S. Teoh wrote:
>> Output:
>> -----------------
>> dead
>> -----------------
>>
>> Truly, DMD's backend is in the bright future of strange and wonderful quantum effects, whereas LDC is clearly still stuck in the antiquated classical past. ;-)
>>
> Sorry, but undefined behaviour is undefined behaviour. The dmd code generator is not at fault here.

With statements like this I always feel like people don't understand what "undefined behavior" means.

All the void initializer does is not initialize the memory of the bool. DMD is testing more than a single bit for a type that is only a single bit, it flip flops between testing a byte and testing a bit. That is most definitely a bug in the DMD backend.

Just to bring up an old debate, this has been argued to not be a bug and is defined behavior and *will not* be changed.

  void foo(bool);
  void foo(byte);

  foo(0); // calls bool
  foo(1); // calls bool
  foo(2); // calls byte

On Saturday, 6 June 2020 at 13:31:31 UTC, Meta wrote:
> On Saturday, 6 June 2020 at 03:56:43 UTC, Timon Gehr wrote:
>> On 06.06.20 05:40, Meta wrote:
>>> 
>>> The linked defect, and the issue you posted, don't really make sense to me. They both have UB; reading from an uninitialized variable (= void), or writing to one member of a union and reading from the other. Invoke Undefined Behaviour and you get... Undefined Behaviour.
>>
>> Right. It's in @safe code.
>
> Ah, yes, I missed that. Why the hell is = void allowed in @safe again? I vaguely remember Walter arguing that it should be for some reason.

Ironically, he argued it's for performance.

On 06.06.20 16:34, Avrina wrote:
> On Saturday, 6 June 2020 at 10:09:07 UTC, Patrick Schluter wrote:
[...]
>> Sorry, but undefined behaviour is undefined behaviour. The dmd code generator is not at fault here.
> 
> With statements like this I always feel like people don't understand what "undefined behavior" means.

I'm not so sure if you really understand what "undefined behavior" means.

By saying this:

> All the void initializer does is not initialize the memory of the bool.

you're defining the behavior of using void initialized values. Once you do that, it's not undefined behavior anymore.

But the spec doesn't do that. Instead it says: "If a void initialized variable's value is used before it is set, the behavior is undefined." That is, the spec explicitly says that doing so is not allowed, and that compilers may assume that it doesn't happen. Because that's what "undefined behavior" means.

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

On Saturday, 6 June 2020 at 14:34:11 UTC, Avrina wrote:
> On Saturday, 6 June 2020 at 10:09:07 UTC, Patrick Schluter wrote:
>> On Friday, 5 June 2020 at 23:53:28 UTC, H. S. Teoh wrote:
>>> Output:
>>> -----------------
>>> dead
>>> -----------------
>>>
>>> Truly, DMD's backend is in the bright future of strange and wonderful quantum effects, whereas LDC is clearly still stuck in the antiquated classical past. ;-)
>>>
>> Sorry, but undefined behaviour is undefined behaviour. The dmd code generator is not at fault here.
>
> With statements like this I always feel like people don't understand what "undefined behavior" means.
>
> All the void initializer does is not initialize the memory of the bool. DMD is testing more than a single bit for a type that is only a single bit, it flip flops between testing a byte and testing a bit. That is most definitely a bug in the DMD backend.

Then it is also a bug in llvm and gcc as they generate the code under exactly the same assumption that a bool is 1 or 0 (and that in C, C++ and D).
Only in contexts where there is int promotion is all the word checked.

This has nothing to do with the D frontend, #pure or whatnot. It's a pure backend code generation assumption.
If the frontend violates that assumption, it is an issue of the frontend.

>
> Just to bring up an old debate, this has been argued to not be a bug and is defined behavior and *will not* be changed.
>
>   void foo(bool);
>   void foo(byte);
>
>   foo(0); // calls bool
>   foo(1); // calls bool
>   foo(2); // calls byte

This has nothing to do with the issue at hand.
This it's a technical choice. It might be surprising, it is very likely a wrong choice, but it is not violation of the assumption of the backend (even if it a violation of the programmer).

On Saturday, 6 June 2020 at 15:16:06 UTC, ag0aep6g wrote:
> On 06.06.20 16:34, Avrina wrote:
>> [...]
> [...]
>> [...]
>
> I'm not so sure if you really understand what "undefined behavior" means.
>
> By saying this:
>
>> [...]
>
> you're defining the behavior of using void initialized values. Once you do that, it's not undefined behavior anymore.
>
> But the spec doesn't do that. Instead it says: "If a void initialized variable's value is used before it is set, the behavior is undefined." That is, the spec explicitly says that doing so is not allowed, and that compilers may assume that it doesn't happen. Because that's what "undefined behavior" means.

The interesting thing is that the compiler detects that case when doing lifetime check, which is only enabled when optimizing. So the issue with the not initialized bool only happens on unoptimized code.

>
> 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