Thread overview | ||||||||
---|---|---|---|---|---|---|---|---|
|
April 24, 2019 Incomplete idea for @safe enhancement | ||||
---|---|---|---|---|
| ||||
'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... |
April 25, 2019 Re: Incomplete idea for @safe enhancement | ||||
---|---|---|---|---|
| ||||
Posted in reply to Nick Sabalausky (Abscissa) | On Thursday, 25 April 2019 at 03:32:03 UTC, Nick Sabalausky (Abscissa) wrote:
> 'Know what I think would be helpful (just because I ran into a case just now where it would help me)...?
>
> [...]
There are situations where you do not have access to the function body, so the compiler cannot assess whether the @system function you are calling is actually
@system.
The easiest way to achieve what you desire is to make @safe default.
|
April 25, 2019 Re: Incomplete idea for @safe enhancement | ||||
---|---|---|---|---|
| ||||
Posted in reply to RazvanN | On Thursday, 25 April 2019 at 06:26:43 UTC, RazvanN wrote:
> On Thursday, 25 April 2019 at 03:32:03 UTC, Nick Sabalausky (Abscissa) wrote:
>> 'Know what I think would be helpful (just because I ran into a case just now where it would help me)...?
>>
>> [...]
>
> There are situations where you do not have access to the function body, so the compiler cannot assess whether the @system function you are calling is actually
> @system.
>
> The easiest way to achieve what you desire is to make @safe default.
A way for the compiler to output all @system functions that could be marked @safe would be great. It's quite annoying to try @safe everywhere manually.
"@system function foo() could be marked @safe"
|
April 25, 2019 Re: Incomplete idea for @safe enhancement | ||||
---|---|---|---|---|
| ||||
Posted in reply to RazvanN | On Thursday, 25 April 2019 at 06:26:43 UTC, RazvanN wrote:
> There are situations where you do not have access to the function body, so the compiler cannot assess whether the @system function you are calling is actually
> @system.
In those situations, the compiler just leaves it alone.
I could see a -vsafe flag that gets as verbose as it can about *potentially* @safe functions, those that aren't but the compiler can see that maybe they could be.
|
April 25, 2019 Re: Incomplete idea for @safe enhancement | ||||
---|---|---|---|---|
| ||||
Posted in reply to Adam D. Ruppe | On Thursday, 25 April 2019 at 12:38:29 UTC, Adam D. Ruppe wrote:
> On Thursday, 25 April 2019 at 06:26:43 UTC, RazvanN wrote:
>> There are situations where you do not have access to the function body, so the compiler cannot assess whether the @system function you are calling is actually
>> @system.
>
> In those situations, the compiler just leaves it alone.
>
> I could see a -vsafe flag that gets as verbose as it can about *potentially* @safe functions, those that aren't but the compiler can see that maybe they could be.
I would argue that this would be a good fit for a 3rd party tool that
uses dmd as a library,
Cheers,
RazvanN
|
April 25, 2019 Re: Incomplete idea for @safe enhancement | ||||
---|---|---|---|---|
| ||||
Posted in reply to RazvanN | On 2019-04-25 14:42, RazvanN wrote: > I would argue that this would be a good fit for a 3rd party tool that > uses dmd as a library, There you go [1]. This will infer all attributes for all functions that are normally not inferred. It will only output attributes that are not already declared. Here's the output of the "src/dmd/root/filename.d" file in DMD: src/dmd/root/filename.d:61:16: this: pure src/dmd/root/filename.d:67:30: equals: @nogc src/dmd/root/filename.d:73:28: equals: @nogc src/dmd/root/filename.d:96:30: absolute: @nogc src/dmd/root/filename.d:102:28: absolute: @nogc src/dmd/root/filename.d:153:38: ext: @nogc src/dmd/root/filename.d:195:31: ext: @nogc src/dmd/root/filename.d:242:38: name: @nogc src/dmd/root/filename.d:248:37: name: @nogc src/dmd/root/filename.d:281:31: name: @nogc src/dmd/root/filename.d:516:29: addExt: pure src/dmd/root/filename.d:577:30: equalsExt: @nogc src/dmd/root/filename.d:583:28: equalsExt: @nogc src/dmd/root/filename.d:604:23: equalsExt: @nogc src/dmd/root/filename.d:972:30: free: pure src/dmd/root/filename.d:982:31: toChars: @nogc src/dmd/root/filename.d:989:19: toString: @nogc I'll try to make a new release tomorrow. There are a few additonal things I would like to add before making a new release. [1] https://github.com/jacob-carlborg/dlp/commit/d41f717aeda7a2a0106d039bde954ab2610e1120 -- /Jacob Carlborg |
Copyright © 1999-2021 by the D Language Foundation