Getting action on your favorite D issues
Avrina
avrina12309412342 at gmail.com
Sun Jun 7 19:01:39 UTC 2020
On Sunday, 7 June 2020 at 14:55:07 UTC, ag0aep6g wrote:
> On Sunday, 7 June 2020 at 13:10:22 UTC, Avrina wrote:
>> It's not though. There is expected behavior for void
>> initializers. Otherwise what you are saying is that C++ has
>> undefined behavior for using variables that aren't initialized
>> (which are all of them unless they are initialized first). But
>> it doesn't. The behavior is expected. The root of the problem
>> isn't with void initialization because the behavior is
>> defined. The problem is with the boolean type and the loose
>> definition the spec provides it. Boolean is undefined behavior
>> in D, as long as the implementation in DMD and LDC differ, and
>> there's nothing in the spec to define it.
>
> The spec clearly says that using an uninitialized value has
> undefined behavior. That doesn't go away just because you don't
> like it, or because C++ doesn't have that rule.
I think we agree on about everything else.
The spec is wrong/incorrect/incomplete in a lot of places, as you
agree. This is just another one. There's nothing an
implementation can do that would reasonably make sense for it
undefined behavior, unlike with something like little/big endian
and unions or bit fields in C++. Reading a void initialized
variable is no different than reading a randomized variable.
Right C++ is more linate with undefined behavior, and it doesn't
even have the rule that D does. Reading uninitialized memory
doesn't change or have any reason to change under any
circumstances. It has no reason to be undefined behavior and is a
mistake in the specs part.
More information about the Digitalmars-d
mailing list