Is @safe still a work-in-progress?

[H. S. Teoh]

On Fri, Aug 17, 2018 at 05:26:48PM +0000, jmh530 via Digitalmars-d wrote:
> On Friday, 17 August 2018 at 14:26:07 UTC, H. S. Teoh wrote:
> > [...]
> > And that is exactly why the whole implementation of @safe is
> > currently rather laughable. By blacklisting rather than
> > whitelisting, we basically open the door wide open to loopholes --
> > anything that we haven't thought of yet could potentially be a
> > @safe-breaking combination, and we wouldn't know until somebody
> > discovers and reports it.
[...]
> Fundamentally, I see it as a good idea. Walter has talked about how
> important memory safety is for D. People thinking their @safe code is
> safe is a big problem when that turns out to not be the case. Imagine
> the black eye D would have if a company was hacked because of
> something like this?

Indeed.


> IMO, the problem is that you can't just replace @safe as it is now.
> You could introduce something like @whitelist or @safewhitelist and
> begin implementing it, but it would probably be some time before it
> could replace @safe. Like when @whitelist is only breaking unsafe
> code.

The way I envision it is that the implementation would begin as a
separate topic branch in the dmd repo, and gradually brought up to the
point where it begins passing the testsuite.  The good thing is that
nowadays with our CI system put in place, any breakages caused in major
D projects like vibe.d would be detected by the autotester, so we can
immediately fill in any obvious missing whitelist items.

Then we'd merge it into master but controlled by a command-line switch,
say -dipxxxx if we put it under a DIP, and put out for 1 or 2 releases.
People who depend on @safe can then opt in to try it out, and report any
bugs (missing whitelist items) that they find.  We fix those bugs until
no more bugs are reported.  Then we make -dipxxxx the default, perhaps
with a reverse switch for reverting to the old @safe implementation just
in case some projects out there depend on it but haven't gotten around
to reporting bugs in the new implementation or whatever.  After another
release or so, we finally remove the switch and delete the old
implementation.

Then going forward, we will have eliminated @safe loopholes pretty much
completely (the only exception being codegen bugs), and the only likely
bugs are missing items in the whitelist.  Which should be much more
manageable and much less disastrous -- the worst that can happen is that
somebody tried to do something legal and got rejected by a big fat
compiler error.  As opposed to today's situation, where somebody tries
something illegal and the compiler fails to detect it, and nobody even
know there's a problem until it becomes an exploitable bug that causes a
security problem.  Given today's security climate, this would be utterly
disastrous for D's reputation.


T

-- 
It is of the new things that men tire --- of fashions and proposals and improvements and change. It is the old things that startle and intoxicate. It is the old things that are young. -- G.K. Chesterton