[Issue 18016] New: using uninitialized value is considered @safe but has undefined behavior

d-bugmail at puremagic.com d-bugmail at puremagic.com
Mon Nov 27 12:18:02 UTC 2017


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

          Issue ID: 18016
           Summary: using uninitialized value is considered @safe but has
                    undefined behavior
           Product: D
           Version: D2
          Hardware: All
                OS: All
            Status: NEW
          Keywords: safe, spec
          Severity: normal
          Priority: P1
         Component: dmd
          Assignee: nobody at puremagic.com
          Reporter: ag0aep6g at gmail.com

Spin-off from issue 15542. Difference is that this issue is about `@safe` where
15542 was about `pure`. 

Code:

----
int f() @safe
{
    int x = void;
    return x;
}
----

This code is currently accepted by dmd, but per the spec it would have to be
rejected.

On `@safe` the spec says: "Safe functions are functions that are statically
checked to exhibit no possibility of undefined behavior." [1]

On void initialization it says: "If the Initializer is void, however, the
variable is not initialized. If its value is used before it is set, undefined
program behavior will result." [2]

So `return x;` has undefined behavior, but `@safe` is supposed to prevent
undefined behavior. `@safe` should make the code not compile.

I see a couple different ways to approach to this:

1) Disallow void initialization in `@safe` code. This would also fix issue
17561 and issue 17566. It would also break existing code that uses void
initialization correctly.

2) Give some defined behavior to void initialized values (without
indirections). For example, say that the value of `x` is unpredictable, but
that the program at large is unaffected (no undefined behavior). With this
approach, issue 15542 would become actual. That is, `pure` would need special
consideration.

3) Water down `@safe` so that it doesn't protect against all undefined
behavior, but only against those instances that break memory safety in
practice. This would seem dangerously unprincipled to me.




[1] https://dlang.org/spec/function.html#function-safety
[2] https://dlang.org/spec/declaration.html#void_init

--


More information about the Digitalmars-d-bugs mailing list