[OffTopic] A vulnerability postmortem on Network Security Services
Timon Gehr
timon.gehr at gmx.ch
Wed Dec 8 18:14:36 UTC 2021
On 08.12.21 18:26, H. S. Teoh wrote:
> Whether @safe is as a blacklist vs a whitelist is IMO an implementation
> detail. I think what Walter is concerned about is more on the higher
> level language perspective: special cases tend to cause unexpected
> interactions with other language features, and such interactions tend to
> percolate throughout the language, adding complexity.
It's not a "special case", it's keeping the core promise of @safe...
Framing this as a special case is just not productive. At that point you
could just as well reason that pointer arithmetic should be allowed in
@safe code. After all, banning it introduces a weird special case that
is inconsistent with how other D code works.
This is a pretty obvious safety hole:
```d
void main()@safe{
struct S{
pragma(mangle,"foo"):
static extern(C) void foo(int){
import core.stdc.stdlib;
free(cast(void*)0xDEADBEEF);
}
static extern(C) void foo()@safe;
}
S.foo();
}
```
There is no @trusted code in that snippet and it frees an invented
pointer. "Memory safety guarantees". The code is not at fault. It's the
language. I am all for pragmatism, but it seems awfully out of touch in
this case.
More information about the Digitalmars-d
mailing list