[Issue 15627] @safe code generates access violation

via Digitalmars-d-bugs digitalmars-d-bugs at puremagic.com
Wed Jun 8 00:54:26 PDT 2016


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

Walter Bright <bugzilla at digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |bugzilla at digitalmars.com
         Resolution|---                         |WONTFIX

--- Comment #1 from Walter Bright <bugzilla at digitalmars.com> ---
What's happening is the .init is insufficient to initialize foo, because local
structs are also initialized with a runtime dynamic link to the stack frame of
the caller. The .init has this field set to null.

Technically, this is not an @safe issue because @safe does not care about null
pointer accesses, because null pointer accesses are not memory safety issues.

Semantically, this case is no different from:

    @safe void foo()
    {
        int* p = null;
        *p = 3;
    }

which will also compile successfully and seg fault at runtime.

If this issue were 'fixed', how would one explain that the pointer init to null
issue is legal but the local struct init to null is not? I suspect that the
cure would be worse than the problem, so I am going to mark this as wontfix.

----------------------------
The program will run successfully if you let the compiler do the
initialization, as in replace:

    FooType foo = FooType.init;

with:

    FooType foo;

--


More information about the Digitalmars-d-bugs mailing list