@trusted assumptions about @safe code

[Paul Backus]

On Wednesday, 27 May 2020 at 15:14:17 UTC, ag0aep6g wrote:
> On 27.05.20 15:43, Paul Backus wrote:
>> I think you are focused in so closely on this particular 
>> example that you are losing track of the bigger picture.
>
> That's entirely possible.
>
>> Knowing that a function is @safe guarantees you that (modulo 
>> errors in @trusted code) it will not violate memory safety 
>> when called with safe arguments. That is the *only* thing 
>> @safe guarantees.
>
> Agreed. The question is: What else can @trusted code rely on, 
> beyond the guarantees of @safe?

If the specific functions it's calling make any additional 
guarantees above and beyond what @safe requires, it can rely on 
those as well.

The question, then, is what constitutes a "guarantee."

> [...]
>> In the case of strlen, you can rely on the wording of the C 
>> standard which states that "The strlen function returns the 
>> number of characters that precede the terminating null 
>> character" to know that if you call it with a null-terminated 
>> string (its precondition), the result will be in-bounds (its 
>> postcondition).
>
> Ok. An @trusted function can rely on the C standard. I take it 
> that an @trusted function can also rely on other documentation 
> of @system functions. So far I'm with you.

It can, to the extent that you trust the code to conform to the 
documentation.

Personally, I am willing to trust libc to conform to the C 
standard, which means that a buggy or non-conforming libc will be 
able to cause memory corruption in @safe programs that I write. 
If you want to take a hard-line stance, you should not trust 
documentation at all.

Note that trusting the D compiler to conform to the D language 
standard is also, in some sense, "trusting documentation." A bug 
in the compiler can always introduce memory corruption to @safe 
code. So "never trust documentation under any circumstances" is 
not really a tenable position in practice.

> From your previous post I figured that this is your position 
> towards calling @safe from @trusted:
>
>     @trusted code is not allowed to rely on the documented
>     return value of an @safe function. The @trusted function
>     must instead verify that the actually returned value is
>     safe to use.

This is my position on *any* function calling *any other* 
function. Even in 100% @system code, I must (for example) check 
the return value of malloc if I want to rely on it not being null.

> I'm not sure if I'm representing you correctly, but that 
> position makes sense to me. At the same time, it doesn't seem 
> feasible, because I don't see how we're going to get users to 
> adhere to that.

Why does it not seem feasible? Checking return values is 
defensive programming 101. People already do this sort of thing 
all the time.

I agree that writing correct @trusted code is difficult, and that 
people are going to make mistakes--just like writing correct C 
code is difficult, and people make mistakes trying to. I don't 
think there's anything we can do in the language itself to fix 
that, other than making it easy to make the @trusted parts of the 
code as small as possible.