[Issue 19968] @safe code can create invalid bools resulting in memory corruption

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=19968

Bolpat  changed:

   What|Removed |Added

 CC||qs.il.paperi...@gmail.com

--- Comment #14 from Bolpat  ---
(In reply to elronnd from comment #13)
> I believe that void initialization of bools should result in their being
> zero-initialized. [...] [S]ince it's as
> cheap to and them with 1 (to get a random result) as to and them with 0
> (which is what mov target, 0 does anyway), zero-initialize them.

It's cheap for a single bool, granted, but consider arrays of bools:

bool[large_num] array = void;

Void init is primarily a thing for static arrays. Silently initializing those
with zeros is basically (performance) code breaking. Note that someone with
writing that code with reasons did that for performance, so it *is* a breaking
change.

--

[Issue 19968] @safe code can create invalid bools resulting in memory corruption

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=19968

elro...@elronnd.net changed:

   What|Removed |Added

 CC||elro...@elronnd.net

--- Comment #13 from elro...@elronnd.net ---
I believe that void initialization of bools should result in their being
zero-initialized.  There is a deeper assumption that bools should be either 0
or 1; that shouldn't be broken by void initialization.  Therefor it should be
ensured that, whatever their value, it's either 0 or 1, and since it's as cheap
to and them with 1 (to get a random result) as to and them with 0 (which is
what mov target, 0 does anyway), zero-initialize them.

--

[Issue 19968] @safe code can create invalid bools resulting in memory corruption

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=19968

--- Comment #12 from ag0aep6g  ---
(In reply to Tim from comment #0)
> import std.stdio;
> void main() @safe
> {
> bool b = void;
> if(b)
> writeln("b seems to be true");
> if(!b)
> writeln("b seems to be false");
> }
> 
> @trusted functions, that are correct for true and false may result in memory
> corruption for invalid values.

I've filed a new issue for this: issue 20148.

--

[Issue 19968] @safe code can create invalid bools resulting in memory corruption

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=19968

Dlang Bot  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #11 from Dlang Bot  ---
dlang/dmd pull request #10055 "fix Issue 19968 - @safe code can create invalid
bools resulting in me…" was merged into master:

- 523e7220017432a9a3db8379f6f827f742c8dff0 by Walter Bright:
  fix Issue 19968 - @safe code can create invalid bools resulting in memory
corruption

https://github.com/dlang/dmd/pull/10055

--

[Issue 19968] @safe code can create invalid bools resulting in memory corruption

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=19968

--- Comment #10 from Tim  ---
(In reply to Dlang Bot from comment #9)
> @WalterBright created dlang/dmd pull request #10055 "fix Issue 19968 - @safe
> code can create invalid bools resulting in me…" fixing this issue:
> 
> - fix Issue 19968 - @safe code can create invalid bools resulting in memory
> corruption
> 
> https://github.com/dlang/dmd/pull/10055

The pull request only fixes the specific example. Here is a new test case, that
is still affected:

import std.stdio;

static int[5] data;
static int[251] data2;

void test(bool b) @safe
{
data[3 + b]++;
}

void main() @safe
{
bool b = void;
writeln(data, data2);
test(b);
writeln(data, data2);   
}

In this case value range propagation determines, that the expression 3 + b is
always in the range of indices for data. But since the type of 3 + b is not
bool anymore, the pull request does not prevent the memory corruption.

In my opinion, it would be better to prevent creating invalid bools in @safe
code.

--

[Issue 19968] @safe code can create invalid bools resulting in memory corruption

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=19968

Dlang Bot  changed:

   What|Removed |Added

   Keywords||pull

--- Comment #9 from Dlang Bot  ---
@WalterBright created dlang/dmd pull request #10055 "fix Issue 19968 - @safe
code can create invalid bools resulting in me…" fixing this issue:

- fix Issue 19968 - @safe code can create invalid bools resulting in memory
corruption

https://github.com/dlang/dmd/pull/10055

--

[Issue 19968] @safe code can create invalid bools resulting in memory corruption

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=19968

--- Comment #8 from Walter Bright  ---
(In reply to Walter Bright from comment #7)
> That is correct. But I don't think this generalizes to other integer types.

Mainly because the compiler doesn't do bounds checking when indexing by bool
and the array size is known to be >= 2.

--

[Issue 19968] @safe code can create invalid bools resulting in memory corruption

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=19968

--- Comment #7 from Walter Bright  ---
> Variables of type bool are expected to be 0 or 1. Using void initialization 
> this invariant can be wrong. This can result in memory corruption.

That is correct. But I don't think this generalizes to other integer types.

--

[Issue 19968] @safe code can create invalid bools resulting in memory corruption

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=19968

Walter Bright  changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com

--- Comment #6 from Walter Bright  ---
(In reply to Tim from comment #5)
> Maybe even types like ubyte can have the same problem on some architectures.
> If a parameter is stored in a register, which is bigger than the type, the
> compiler could assume the value is in the correct range. But an
> uninitialized variable could result in an uninitialized register.

When registers load a ubyte, and then the whole register is used, there must
have been a conversion from ubyte to the larger size first, so I don't think
this is an issue.

--

[Issue 19968] @safe code can create invalid bools resulting in memory corruption

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=19968

--- Comment #5 from Tim  ---
Maybe even types like ubyte can have the same problem on some architectures. If
a parameter is stored in a register, which is bigger than the type, the
compiler could assume the value is in the correct range. But an uninitialized
variable could result in an uninitialized register.

--

[Issue 19968] @safe code can create invalid bools resulting in memory corruption

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=19968

--- Comment #4 from ag0aep6g  ---
(In reply to timon.gehr from comment #3)
> Also, the spec currently states:
> 
> "Undefined Behavior: If a void initialized variable's value is used before
> it is set, the behavior is undefined."
> 
> https://dlang.org/spec/declaration.html#void_init
> 
> Unless this is changed (and I don't see a compelling reason to), there can't
> be _any_ `void` initialization in @safe code.

That's issue 18016, and Walter has an open PR to resolve it by changing the
spec: .

--

[Issue 19968] @safe code can create invalid bools resulting in memory corruption

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=19968

--- Comment #3 from timon.g...@gmx.ch ---
Also, the spec currently states:

"Undefined Behavior: If a void initialized variable's value is used before it
is set, the behavior is undefined."

https://dlang.org/spec/declaration.html#void_init

Unless this is changed (and I don't see a compelling reason to), there can't be
_any_ `void` initialization in @safe code.

--

[Issue 19968] @safe code can create invalid bools resulting in memory corruption

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=19968

timon.g...@gmx.ch changed:

   What|Removed |Added

 CC||timon.g...@gmx.ch

--- Comment #2 from timon.g...@gmx.ch ---
Note that there is a general problem with `void` initialization, not only of
bools but for all data types that have a (possibly implicit) invariant. If
@safe code can `void`-initialize a struct with private members, @trusted code
can't establish any invariants, which would cripple it.

--

[Issue 19968] @safe code can create invalid bools resulting in memory corruption

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=19968

ag0aep6g  changed:

   What|Removed |Added

   Keywords||safe
 CC||ag0ae...@gmail.com

--

[Issue 19968] @safe code can create invalid bools resulting in memory corruption

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=19968

--- Comment #1 from Tim  ---
The ABI specifies, that bool are 0 or 1:
https://dlang.org/spec/abi.html#basic_types

There are multiple options to solve this bug:
1. Make sure @safe code can not create invalid bools.
2. Change the ABI, so all values are valid. This could result in slower code
being generated.

--