[OffTopic] A vulnerability postmortem on Network Security Services

H. S. Teoh hsteoh at quickfur.ath.cx
Thu Dec 2 17:49:51 UTC 2021


On Thu, Dec 02, 2021 at 05:39:11PM +0000, Tejas via Digitalmars-d wrote:
> On Thursday, 2 December 2021 at 17:36:18 UTC, H. S. Teoh wrote:
[...]
> > The solution is very simple: extern(C), extern(C++), and extern
> > anything except extern(D) really, should be @system, and extern(D)
> > (the default) should be @safe.
> > 
> > The real issue is convincing Walter to accept this.
[...]
> You'll have to atleast create `@trusted` wrappers around each such
> function though, if you want normal D functions to call them :(
> 
> That's why I feel we should allow `@trusted` to be annotated on
> `extern` functions.

I thought that was obvious?  We're talking about @system **by default**
here.  It does not preclude marking extern(C) declarations as @trusted.

Though TBH, that in itself is suspect; a function like memcpy, for
example, CANNOT be marked @trusted because it does not have a safe API:
the caller can easily pass a wrong argument to memcpy and it will
overrun the buffer.  Marking such a thing as @trusted undermines @safe,
and we're back to square one w.r.t. memory safety.

Unfortunately, this is exactly what most people will do, because they
just want the compile error to go away and stop bothering them. So in
name their code is @safe, but it doesn't mean very much in actuality
because there are badly-tagged @trusted functions inside where who knows
what can happen.


T

-- 
Живёшь только однажды.


More information about the Digitalmars-d mailing list