Safety audit and the overlooked emergency exit

Bastiaan Veelo Bastiaan at Veelo.net
Tue May 26 15:01:06 UTC 2020


I think there is an exit to the current impasse that has been 
overlooked thus far.

The key question is, during a safety audit, how to find the 
unsafe sections of code that need to be vetted thoroughly. If DIP 
1028 is kept as is, these sections can be found by `grep 
@trusted|extern\(C`. If DIP 1028 would be amended as many argue 
for, it would be `grep @trusted`. But isn't grep a rather crude 
tool, and wouldn't the compiler be able to create more useful 
reports either way?

The compiler already has options for listing gc allocations 
(-vgc) and variables that go into thread local storage (-vtls). A 
new option could be implemented to list all @trusted functions 
and all calls into extern(C[++]) functions from within safe 
sections.

It is the calls into extern(C[++]) functions that cannot be 
guaranteed to be safe, irrespective of whether the declarations 
are marked @trusted or @safe. So listing these calls is much more 
valuable than grepping for @trusted, which can be misused as 
"@trusted extern(...". If a C library has a proper D wrapper that 
defines a safe interface, only the @trusted functions in the 
wrapper would appear in the list, not the extern(C) calls that 
are made within its @trusted functions. The list could possibly 
be reduced by excluding functions that are never called, making 
it even more valuable.

@trusted is not a seal of approval. It bears no signature, nor a 
hash of the implementation. It is simply a bridge from safe 
territory into unsafe territory, and is a checkpoint that cannot 
be skipped in any certification process.

Considering this, the compiler can actually produce a hash of the 
implementation of trusted functions as part of this list. A 
certification authority can then actually use this list to 
maintain a table of sections, hashes and stamps. If a new release 
needs to renew its certification, the earlier table can be 
compared against the current list, and functions whose hash 
didn't change need not be reviewed again. Extrapolating even 
further, this could be the basis of a repository of approvals 
from various individuals and authorities representing statements 
like "I have looked at this function carefully and I believe it 
can indeed be trusted".

I think this would be a tool that adds real practical value and 
helps to reduce the cost of audits. And not the least, regarding 
the current discussion, it diminishes the importance of whether 
extern(C[++]) declarations are actually @system or @safe.

-- Bastiaan.


More information about the Digitalmars-d-announce mailing list