@system blocks and safer @trusted (ST) functions

claptrap clap at trap.com
Sun Jul 25 23:34:35 UTC 2021


On Sunday, 25 July 2021 at 22:43:26 UTC, Paul Backus wrote:
> On Sunday, 25 July 2021 at 22:05:26 UTC, claptrap wrote:
>>
>> Im sorry but it's nonsense.
>>
>> You get an OOB error, it points you at the system block, you 
>> add bounds checking, job done.
>>
>> Changing favouriteNumber doesnt introduce a bug, the bug was 
>> *already* there in the system block.
>>
>> You cant expect favouriteNumber to be responsible for other 
>> code doing stupid things with its result.
>
> If the bug is "already there", you should be able to write a 
> program that uses the unmodified versions of `favoriteNumber` 
> and `favoriteElement` to cause undefined behavior in `@safe` 
> code.
>
> If you cannot, then you must admit that `favoriteElement` is 
> memory safe as-written.

Consider this...

int foo() { return 42; }

void bar()
{
     int[2] what;
     if (foo() == 24)
     {
        what.ptr[2] = 100; // BUG
     }
}

Your argument the same as saying that bar() is memory safe as 
written. True, but it's not bug free. The bug is just waiting for 
the right set of circumstances to come to life and eat your face 
:)

IE. Memory safe as written != bug free



More information about the Digitalmars-d mailing list