http://d.puremagic.com/issues/show_bug.cgi?id=3925

           Summary: Missed escaping reference of a local variable
           Product: D
           Version: 2.041
          Platform: x86
        OS/Version: Windows
            Status: NEW
          Keywords: diagnostic
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: nobody@puremagic.com
        ReportedBy: bearophile_hugs@eml.cc


--- Comment #0 from bearophile_hugs@eml.cc 2010-03-10 07:38:56 PST ---
This is a wrong program, and the compiler shows the right error messages, of x and y escaping:


ref int foo(int x) {
    return x;
}
int* baz() {
    int y;
    return &y;
}
void main() {}

-------------------


But in the following case the compiler doesn't show an error:


ref int foo(ref int x) {
    return x;
}
ref int bar() {
    int x;
    return foo(x); // escaping reference of x
}
void main() {}

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3925



--- Comment #1 from bearophile_hugs@eml.cc 2010-03-10 10:08:04 PST ---
This was the original code by Michel Fortin:

@safe ref int foo(ref int a) {
    return a;
}
@safe ref int bar() {
    int a;
    return foo(a);
}


Norbert Nemec comments:
>I would say the possibility of a bug makes this code unsafe by definition. Ref returns must be considered unsafe by default, unless the compiler can know for sure that the object will exist beyond the lifetime of the function.<


So I think Norbert Nemec idea is: while the normal compiler error messages assume correctness and need a demonstration of unsafety to be shown, @safe can do the opposite assuming unsafety and requiring a demonstration of safety.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3925


Don <clugdbug@yahoo.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |clugdbug@yahoo.com.au


--- Comment #2 from Don <clugdbug@yahoo.com.au> 2010-03-10 11:12:03 PST ---
(In reply to comment #1)
> This was the original code by Michel Fortin:
> 
> @safe ref int foo(ref int a) {
>     return a;
> }
> @safe ref int bar() {
>     int a;
>     return foo(a);
> }
> 
> 
> Norbert Nemec comments:
> >I would say the possibility of a bug makes this code unsafe by definition. Ref returns must be considered unsafe by default, unless the compiler can know for sure that the object will exist beyond the lifetime of the function.<
> 
> 
> So I think Norbert Nemec idea is: while the normal compiler error messages assume correctness and need a demonstration of unsafety to be shown, @safe can do the opposite assuming unsafety and requiring a demonstration of safety.

I've just been dealing with ref returns in my recent CTFE patch. But I don't
think it's very complicated.
As far as I can tell, ref returns are only a problem if a local variable is
passed as a ref parameter, or if it is a member function of a local struct.
If either of those is true, it should be considered to potentially be a return
of a local variable.
I don't think there's any problem with foo, but bar should generate an error.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3925


Michel Fortin <michel.fortin@michelf.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |michel.fortin@michelf.com


--- Comment #3 from Michel Fortin <michel.fortin@michelf.com> 2010-03-10 15:04:05 EST ---
(In reply to comment #2)
> I've just been dealing with ref returns in my recent CTFE patch. But I don't
> think it's very complicated.
> As far as I can tell, ref returns are only a problem if a local variable is
> passed as a ref parameter, or if it is a member function of a local struct.
> If either of those is true, it should be considered to potentially be a return
> of a local variable.
> I don't think there's any problem with foo, but bar should generate an error.

This seems fair. There is a similar problem with delegates:

@safe
void delegate() foo(ref int a) {
    return { writeln(a); };
}

@safe
void delegate() bar() {
    int a;
    return foo(a); // leaking reference to a beyound bar's scope
}

It could be solved in the same way.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3925



--- Comment #4 from bearophile_hugs@eml.cc 2010-10-22 19:26:06 PDT ---
Here DMD 2.049 doesn't find the error, but it should:


int* foo() {
    int x;
    int* p = &x;
    return p;
}
void main() {}

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3925



--- Comment #5 from Sobirari Muhomori <dfj1esp02@sneakemail.com> 2010-10-25 13:59:45 PDT ---
---
class A{}

A foo(A a)
{
    return a;
}

A bar()
{
    scope A a=new A();
    return foo(a);
}
---

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3925



--- Comment #6 from bearophile_hugs@eml.cc 2010-10-25 15:40:48 PDT ---
(In reply to comment #5)
> ---
> class A{}
> 
> A foo(A a)
> {
>     return a;
> }
> 
> A bar()
> {
>     scope A a=new A();
>     return foo(a);
> }
> ---

The "scope" is deprecated, so I think yours isn't a valid error case, sorry :-(

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3925



--- Comment #7 from bearophile_hugs@eml.cc 2011-06-29 15:32:18 PDT ---
Two more cases of undetected escaping of reference:


int* ptr;
void foo1() {
    int local;
    ptr = &local;
}
void foo2(int** x) {
    int i;
    *x = &i;
}
void main() {}


See also bug 5541 and bug 1313

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------