Bug 22215 – returning expired stack pointers in @system code allowed by spec, not by implementation
Status
RESOLVED
Resolution
FIXED
Severity
minor
Priority
P1
Component
dlang.org
Product
D
Version
D2
Platform
All
OS
All
Creation time
2021-08-16T15:02:41Z
Last change time
2022-03-08T11:06:31Z
Keywords
pull, safe
Assigned to
No Owner
Creator
Ate Eskola
Comments
Comment #0 by Ajieskola — 2021-08-16T15:02:41Z
This does not compile with -dip1000:
```
int* f()
{ int x = 42;
return &x;
}
```
There is a workaround that compiles:
```
int* f()
{ int x = 42;
auto wannaBePointer = cast(size_t)&x;
return cast(typeof(return)) wannaBePointer;
}
```
But according to the spec, only `@safe` code must analyzed with -dip1000 so this workaround should not be required.
Comment #1 by dkorpel — 2021-08-16T19:55:37Z
It doesn't compile without -dip1000 either, the error predates it.
> this workaround should not be required.
Intentionally returning an expired stack pointer should be a very rare occurrence, I think a workaround is warranted. However, the spec says:
> @system functions may perform any operation legal from the perspective of the language including inherently memory unsafe operations like returning pointers to expired stackframes
https://dlang.org/spec/memory-safe-d.html
So at least one has to change: the implementation, or the spec.
Comment #2 by Ajieskola — 2021-08-25T17:07:57Z
There appears to be two bugs, one in vanilla DMD and one with -dip1000.
As Dennis said, my initial example fails to compile regardless of the compiler switches used. But there is a watered-down version of my workaround:
```d
int* f()
{ int x = 42;
auto wannaBePointer = &x;
return wannaBePointer;
}
```
This one compiles with vanilla DMD, but the -dip1000 bug prevents compiling it with the said flag.
The full workaround in the initial example still compiles with the flag too.
Comment #3 by dkorpel — 2021-08-25T18:24:03Z
(In reply to Ate Eskola from comment #2)
> There appears to be two bugs, one in vanilla DMD and one with -dip1000.
That's right, the latter one is https://issues.dlang.org/show_bug.cgi?id=19873
Comment #4 by bugzilla — 2022-02-17T07:59:27Z
We shouldn't fix this. It's such an easy mistake to make, with terrible consequences. Allowing the wannaBePointer workaround is good enough.
Downgraded this to 'minor'.
Probably an adjustment to the spec would be better.
Comment #5 by bugzilla — 2022-02-17T08:03:12Z
Changed it to a spec bug.
Comment #6 by dlang-bot — 2022-03-07T16:33:14Z
@dkorpel created dlang/dlang.org pull request #3246 "Fix issue 22215 - returning expired stack pointers in `@system` code …" fixing this issue:
- Fix issue 22215 - returning expired stack pointers in `@system` code allowed by spec, not by implementation
https://github.com/dlang/dlang.org/pull/3246
Comment #7 by dlang-bot — 2022-03-08T11:06:31Z
dlang/dlang.org pull request #3246 "Fix issue 22215 - returning expired stack pointers in `@system` code …" was merged into master:
- 0e09baaf7bb31a3eaea6fb28359d11cc8a20276f by Dennis Korpel:
Fix issue 22215 - returning expired stack pointers in `@system` code allowed by spec, not by implementation
https://github.com/dlang/dlang.org/pull/3246