Bug 18756 – Escaping address of temporary struct field

Status
RESOLVED
Resolution
INVALID
Severity
normal
Priority
P1
Component
dmd
Product
D
Version
D2
Platform
All
OS
All
Creation time
2018-04-12T09:38:07Z
Last change time
2020-03-04T10:06:35Z
Keywords
accepts-invalid, safe
Assigned to
No Owner
Creator
Nick Treleaven
See also
https://issues.dlang.org/show_bug.cgi?id=20183

Comments

Comment #0 by nick — 2018-04-12T09:38:07Z
@safe unittest { struct S { int i; } auto p = &S().i; } This compiles without error with dmd v2.079.0, with or without -dip1000. Adding a destructor to S does trigger an error. Also, *without* -dip1000, this @safe code fails to error: S s; auto p = &s.i;
Comment #1 by greeenify — 2018-04-12T19:24:03Z
Taking an address is allowed in dip1000 and also @safe I don't see any violation of safety in your example. The thing that isn't allowed is storing the address or returning it (though that is sometimes allowed when the compiler can guarantee that it will be @safe). So AFAICT this is invalid?
Comment #2 by issues.dlang — 2018-04-13T03:28:44Z
Without -dip1000, & is not @safe. So, it's bug in that sense regardless. But on top of that, it's taking the address of a _temporary_. It's never @safe to take the address of a temporary and ideally, it wouldn't even be allowed in @sytem code, because it's always a bug.
Comment #3 by dfj1esp02 — 2018-04-16T08:24:29Z
(In reply to Jonathan M Davis from comment #2) > because it's always a bug. It's correct when the result is passed to a function parameter.
Comment #4 by issues.dlang — 2018-04-16T09:31:17Z
(In reply to anonymous4 from comment #3) > (In reply to Jonathan M Davis from comment #2) > > because it's always a bug. > It's correct when the result is passed to a function parameter. How so?
Comment #5 by nick — 2019-08-30T15:50:30Z
Still present with DMD32 D Compiler v2.088.0-rc.1
Comment #6 by bugzilla — 2020-03-04T10:06:35Z
The compiler is working as designed.