@trusted attribute should be replaced with @trusted blocks
Timon Gehr
timon.gehr at gmx.ch
Thu Jan 16 00:14:05 UTC 2020
On 16.01.20 00:24, IGotD- wrote:
> On Wednesday, 15 January 2020 at 23:01:57 UTC, Joseph Rushton Wakeling
> wrote:
>>
>> Presumably your programs are therefore self-crafted binary, since you
>> couldn't possibly trust the humans who wrote the standard library to
>> write valid code, or the compiler writers to translate it correctly
>> into machine instructions? :-)
>>
>
> @safe is a subset of D that guarantees no memory corruption.
@safe does not mean "this unconditionally can not corrupt memory", it
says "if its @trusted dependencies are written right, @safe code can not
introduce memory corruption". If you don't write @trusted code yourself
and only use the standard library, @safe gives you the guarantee you
mention per the language and standard library specification, but in
practice there can be bugs in the language implementation or its
dependencies. Assuming a correct compiler implementation of the safety
checks, the locations where memory corruption can be caused will however
all be within `@trusted` function calls.
Similar concerns apply to other safe languages such as Java. (Why do you
think users need to update their JVM regularly? It's not just about
performance upgrades.) What do you think "security updates" for your OS
do? How is @safe supposed to be _useful_ if it cannot assume the OS,
system C libraries, and hardware behave as specified?
> The only
> way to ensure this is if the compiler have all the source code (will
> object code also work?) and can check that all the calls are also @safe.
> If this condition is not met, it is not safe by definition. @trusted
> code has reduced memory guarantees and can also call unsafe code further
> along the line and therefore unsafe.
>
> @trusted is therefore impossible and the criteria cannot be met. It's
> just a badge meaning nothing.
> ...
Nonsense. It's the place where you inject assumptions into your
conditional verifier. It reduces the amount of code you have to audit to
convince yourself that a given dependency will not corrupt the internal
state of your program.
>> I think you're getting caught up on the choice of terminology. It's
>> just a hierarchy of guarantees:
>
> No, I'm caught up in the semantics. I see that a condition cannot be met
> and therefore unnecessary.
You are operating on bad assumptions or bad logic. @trusted is clearly
useful, because it makes no sense to require every piece of trusted code
to be part of the compiler implementation.
> @trusted is an oxymoron.
>
@trusted void foo(int[] a,int b){
if(0<=b&&b<a.length){
a.ptr[b]=2;
}
}
@system void bar(int[] a,int b){
a.ptr[b]=2;
}
How do you not see the difference, that it is useful to annotate that
difference, and that it is okay to call foo from @safe code, but not bar?
More information about the Digitalmars-d
mailing list