[OffTopic] A vulnerability postmortem on Network Security Services

[Timon Gehr]

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.