Jump to page: 1 2
Thread overview
[Issue 19968] @safe code can create invalid bools resulting in memory corruption
Jun 15, 2019
Tim
Jun 15, 2019
ag0aep6g
Jun 15, 2019
timon.gehr@gmx.ch
Jun 15, 2019
timon.gehr@gmx.ch
Jun 15, 2019
ag0aep6g
Jun 15, 2019
Tim
Jun 17, 2019
Walter Bright
Jun 17, 2019
Walter Bright
Jun 17, 2019
Walter Bright
Jun 18, 2019
Dlang Bot
Jun 18, 2019
Tim
Jul 22, 2019
Dlang Bot
Aug 20, 2019
ag0aep6g
Jun 08, 2020
Bolpat
June 15, 2019
https://issues.dlang.org/show_bug.cgi?id=19968

--- Comment #1 from Tim <tim.dlang@t-online.de> ---
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.

--
June 15, 2019
https://issues.dlang.org/show_bug.cgi?id=19968

ag0aep6g <ag0aep6g@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |safe
                 CC|                            |ag0aep6g@gmail.com

--
June 15, 2019
https://issues.dlang.org/show_bug.cgi?id=19968

timon.gehr@gmx.ch changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |timon.gehr@gmx.ch

--- Comment #2 from timon.gehr@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.

--
June 15, 2019
https://issues.dlang.org/show_bug.cgi?id=19968

--- Comment #3 from timon.gehr@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.

--
June 15, 2019
https://issues.dlang.org/show_bug.cgi?id=19968

--- Comment #4 from ag0aep6g <ag0aep6g@gmail.com> ---
(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: <https://github.com/dlang/dlang.org/pull/2260>.

--
June 15, 2019
https://issues.dlang.org/show_bug.cgi?id=19968

--- Comment #5 from Tim <tim.dlang@t-online.de> ---
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.

--
June 17, 2019
https://issues.dlang.org/show_bug.cgi?id=19968

Walter Bright <bugzilla@digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugzilla@digitalmars.com

--- Comment #6 from Walter Bright <bugzilla@digitalmars.com> ---
(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.

--
June 17, 2019
https://issues.dlang.org/show_bug.cgi?id=19968

--- Comment #7 from Walter Bright <bugzilla@digitalmars.com> ---
> 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.

--
June 17, 2019
https://issues.dlang.org/show_bug.cgi?id=19968

--- Comment #8 from Walter Bright <bugzilla@digitalmars.com> ---
(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.

--
June 18, 2019
https://issues.dlang.org/show_bug.cgi?id=19968

Dlang Bot <dlang-bot@dlang.rocks> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |pull

--- Comment #9 from Dlang Bot <dlang-bot@dlang.rocks> ---
@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

--
« First   ‹ Prev
1 2