• Nick Sabalausky (Abscissa) (29/29) Apr 24 2019 'Know what I think would be helpful (just because I ran into a case just...
• RazvanN (8/11) Apr 24 2019 There are situations where you do not have access to the function
• Zoadian (5/17) Apr 25 2019 A way for the compiler to output all @system functions that could
• Adam D. Ruppe (5/9) Apr 25 2019 In those situations, the compiler just leaves it alone.
• RazvanN (6/15) Apr 25 2019 I would argue that this would be a good fit for a 3rd party tool
• Jacob Carlborg (28/30) Apr 25 2019 There you go [1]. This will infer all attributes for all functions that

"Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:

'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...

RazvanN <razvan.nitu1305 gmail.com> writes:

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.

Zoadian <no no.no> writes:

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"

Adam D. Ruppe <destructionator gmail.com> writes:

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.

RazvanN <razvan.nitu1305 gmail.com> writes:

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

Jacob Carlborg <doob me.com> writes:

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