misplaced @trust?

H. S. Teoh via Digitalmars-d digitalmars-d at puremagic.com
Thu Feb 5 12:10:56 PST 2015


On Thu, Feb 05, 2015 at 11:49:40AM -0800, Andrei Alexandrescu via Digitalmars-d wrote:
> On 2/5/15 11:17 AM, H. S. Teoh via Digitalmars-d wrote:
> >In short, my proposal is:
> 
> Tainted variables are an interesting topic, but quite distinct from
> the notion of separating safe code from unsafe code.
> 
> As much as I was shocked about the use of @trusted/@safe/@system in
> std.file, std.array and sadly possibly in other places, I found no
> evidence that the feature is misdesigned. I continue to consider it a
> simple, sound, and very effective method of building and interfacing
> robust code. An excellent engineering solution that offers a lot of
> power at a modest cost.

Frankly, I don't understand how you could fail to see the maintenance
nightmare @trusted, as you envisioned it, is causing. The wholesale
license to freely perform @system operations inside a @trusted function
greatly undermines the trustworthiness of SafeD as a whole. The problem
is that human verification only happens once, and thereafter @trusted
continues to be applied to that function, even if later on, further
downstream in the call graph, a remote helper function has changed in a
way that compromises that trustworthiness. This happens with no warnings
whatsoever from the compiler, and so we continue to build our house upon
sinking sand.

To truly be sure that our @trusted functions are actually trusted, we
have to continually review them not just for changes within the function
bodies, but also all downstream functions used within. The review
requirements for maintaining such a standard is impractically onerous.
And, judging from the trends in our industry, what will likely happen is
that this review is never actually carried out until a nasty security
exploit is discovered in @safe code. By then, it will be far too late.
Maybe to you this situation is acceptable, but to me, this is an utter
maintenance nightmare.


> I do not support this proposal to change the semantics of
> @trusted/@safe/@system. A separate tainted data proposal might be of
> interest for loosely related topics.
[...]

That is your own prerogative, but this discussion has convinced me that
@safe is a joke, and your continual refusal to admit the existence of
any problems despite many active Phobos contributors describing it to
you in detail has made me completely lose interest in this subject. From
now on I will not bother with @safe in my projects anymore, since it has
become clear that it does not live up to its promise and probably never
will (this specific issue is only the tip of the iceberg; there are many
other problems with @safe that you may find in bugzilla), and I have no
further interest in contributing to @safe-related issues in Phobos.


T

-- 
Mediocrity has been pushed to extremes.


More information about the Digitalmars-d mailing list