@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