[OffTopic] A vulnerability postmortem on Network Security Services

[H. S. Teoh]

On Wed, Dec 08, 2021 at 04:47:20PM +0000, jmh530 via Digitalmars-d wrote:
> On Wednesday, 8 December 2021 at 15:46:31 UTC, Steven Schveighoffer wrote:
[...]
> > I proposed [during the
> > discussion](https://forum.dlang.org/post/r6kvm4$1vq5$1@digitalmars.com)
> > that you can assume `extern(C)` functions are `@safe` as long as
> > they are mangled differently. I think that would both solve the
> > problems people had, and allow `extern(C)` to be safe by default.
> > 
> > Walter seemingly ignored it, but silently [hated
> > it](https://forum.dlang.org/post/ra7958$2r8v$1@digitalmars.com), so
> > I don't see that happening.
[...]
> I think Walter (and likely Atila too) might come down on avoiding
> special casing as an important design goal.
> 
> To me, the best way to ensure that is to moving @safe from a black
> list to an white list. That is, @safe is currently structured so that
> you cannot do certain things. If instead it is structured so that only
> certain things are allowed, then something like having the body of the
> function available could be on that list. There would be no more
> special casing and it would only break code to the extent that the
> white list and black list do not match up (which might be
> considerable, who knows)

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.

I'm somewhat sympathetic to this view, but I think in this case it has
unfortunately devolved into the perfect being the enemy of the good. For
pragmatic reasons I would have allowed this, had the decision been up to
me.


T

-- 
I am a consultant. My job is to make your job redundant. -- Mr Tom