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