Incomplete idea for @safe enhancement
Nick Sabalausky (Abscissa)
SeeWebsiteToContactMe at semitwist.com
Thu Apr 25 03:32:03 UTC 2019
'Know what I think would be helpful (just because I ran into a case just
now where it would help me)...?
We have @safe which adds extra checks to help guard against memory
safety issues. Right? Sounds good.
And @safe is "turtles all the way down", ie, a function cannot be @safe
unless everything it calls it also @safe. Again, sure, makes logical sense.
But now, I'm debugging an @system function. And the bug appears to be
something which might be catchable via @safe, for example:
std.exception.ErrnoException@[...]/phobos/std/stdio.d(2890): Enforcement
failed (Bad address)`
But the function(s) under suspicion call other functions which are
@system. That means, if I mark the function I'm debugging as @safe, the
compile errors I get only just freak out about the fact that that I'm
calling a bunch of @system functions, and (AFAIK) they may-or-may-not
actually give me any information about memory-safety flaws withing the
function in question. (And in my particular case, they do *not* yield
useful information beyond freaking out about calls to @system functions.
Maybe that's because there genuinely aren't any memory-safety issues in
the functions I'm checking...but I have no way of knowing that.)
Soo.....
What about some way to run the @system checks on an @system function for
diagnostic purposes, without letting the compiler get hung up on, and
obsess over the "turtles all the way down" requirement before yielding
any useful diagnostics...?
Good idea?
Bad idea?
Infeasible idea?
Already possible idea?
Discuss...
More information about the Digitalmars-d
mailing list