@trusted assumptions about @safe code

[Dukc]

On Tuesday, 26 May 2020 at 00:22:05 UTC, ag0aep6g wrote:
> On 26.05.20 01:47, Dukc wrote:
>> No, `f` should be just dead `@system`. If you call f with a 
>> string which does not point to null, but is empty, boom!
>
> Right. I can fix that by changing
>
>     immutable(char)* c = s.ptr;
>
> to
>
>     immutable(char)* c = &s[0];
>
> correct?
>
> [...]

Looks good to me. Well, not sure about that mutable aliasing 
thing others have mentioned, maybe it's good, maybe not.

>> I don't think it as a problem for `@safe`. `@safe` is just a 
>> command to turn the memory checking tool on, not a code 
>> certification (although using @safe where possible would 
>> probably be required for certifying).
>
> And you don't think it's possible and worthwhile to strengthen 
> @safe so far that it becomes a code certification?
>

No, even if @safe would in all instances be 100% idiot-proof 
memory safe, I think it would work badly as a code certificate. 
Why? It would mean that if you have an already `@safe` function 
that would be fit for use in `@system` code, you would have to 
either duplicate it or disable it's memory checks, because it 
could not be certified for `@system` code.

The closest thing to a certificate a code can have AFAIK is an 
automatic test suite. `@safe` works well in conjunction with such 
a test suite: if a function is both `@safe` and `pure`, you know 
that regular `unittest`s are enough to certify it in the general 
case. With `@system` or `@trusted`, Valgrinding might be required.

This also applies to your example: Had you tested that `g` does 
not mutate the pointed value (or set the parameter as `const`), 
the bug would have been caught. On the other hand, no amount of 
unit testing can alone certify `f` to a high standard, as it 
could still silently be corrupting the memory despite outputting 
and returning correctly