digitalmars.D.bugs - [Issue 18016] New: using uninitialized value is considered safe but
- d-bugmail puremagic.com (49/49) Nov 27 2017 https://issues.dlang.org/show_bug.cgi?id=18016
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 puremagic.com Reporter: ag0aep6g 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 --
Nov 27 2017