On Friday, 6 February 2015 at 15:14:14 UTC, Wyatt wrote:
On Friday, 6 February 2015 at 13:42:40 UTC, Ola Fosheim Grøstad
wrote:
"cannot modify this without detailed review".
This quote from Ola, here? That basically describes my job
maintaining big piles of legacy C: the compiler verifies
nothing, so every change to the anything in the API of "safe"
functions or anything in their entire call chain must be
painstakingly reviewed.
A single change generally takes me several days of research,
verification, and testing. I fixed about 150 potential memory
issues (and several really dumb logic errors) with Clang's
static analysis when I first inherited the code; it took weeks.
(And now writing new stuff using this "safe" API is turning up
memory safety issues anyway!)
So from my perspective, calling this situation "completely
impractical" reveals a stunning gift for understatement. Is
this really the best we can do after however many years?
Because it blows.
The current @trusted semantics (and accompanying politics) make
it exceedingly clear that @safe is meaningless for anything
beyond trivial, one-off tools that will never receive
maintenance.
-Wyatt
Exactly the reason why I never liked C and C++ only makes it
better if everyone on team stays away from Cisms and uses the
safer alternatives.
Now the C and C++ world finally accepted the use of static
analyzers, but I had the displeasure to try to find pointer
related issues without one, back in the .com days. As you say, it
takes weeks.
Regarding D, maybe @trusted should go away and only keep @system
(== unsafe in other languages), as it can hardly give any extra
security guarantee.
However, I don't see how to solve the human review process, as
that is an halting problem.
--
Paulo
