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

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

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

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

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

--- Comment #12 from ag0aep6g <ag0aep6g@gmail.com> ---
(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.

--
January 06, 2020
https://issues.dlang.org/show_bug.cgi?id=19968

elronnd@elronnd.net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |elronnd@elronnd.net

--- Comment #13 from elronnd@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.

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

Bolpat <qs.il.paperinik@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |qs.il.paperinik@gmail.com

--- Comment #14 from Bolpat <qs.il.paperinik@gmail.com> ---
(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.

--
1 2
Next ›   Last »