www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - return table from local resource

reply "monarch_dodra" <monarch_dodra gmail.com> writes:
Just started using D. I've got a very strong background in C++. I
was making this toy program:

[CODE]import std.stdio;

int[] fun()
{
     int[3] statictab;
     writeln(statictab);
     int[] dyntab = statictab;
     writeln(dyntab);
     return dyntab;
}

void main()
{
     int[] a = fun();
     writeln(a);
}[/CODE]

First, I create a method called "fun". In it, I create on the
stack a table. I create a dynamic array that references that
table. I return the dynamic array.

Of course, this is the classic "return reference to local"
problem. I can tell the problem is there because the output I get
is:

[CODE]
[0, 0, 0]
[0, 0, 0]
[1637924, 4217180, 10] //Garbage
[/CODE]

What bothers me is that it was my understanding that the D
language standard protected me from this kind of undefined
behavior. I did make use of anything unsafe, so what gives?
Compiler not catch it but should have?

Or am I just mistaken about the safe guarantees of D?

What bothers me even more is this:

[CODE] safe

int[] fun()
{
     int[3] statictab;
     int[] dyntab = statictab;
     return dyntab;
}

void main()
{
     int[] a = fun();
}
[/CODE]

This time, in "Safe" mode...
Jun 25 2012
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
monarch_dodra:


 What bothers me is that it was my understanding that the D
 language standard protected me from this kind of undefined
 behavior. I did make use of anything unsafe, so what gives?
 Compiler not catch it but should have?


Currently the compiler doesn't track where is located the memory 
of dynamic array slices. In general it's hard to perform this 
analysis, so I think the D compiler isn't supposed to catch all 
such bugs.

On the other hand a certain amount of logic to statically detect 
simple cases like this one should be added. Maybe you want to add 
this as a Bugzilla enhancement request. If you have a strong C++ 
background you may even be able to write a patch in GitHub that 
implements a basic form of such static analysis.

Regarding  safe, it can't help you here. Since day 0 I've said 
 safe is a named wrongly, because it just refers to a narrow 
definition of memory safety, that doesn't include the class of 
bugs discussed here.

Bye,
bearophile
Jun 25 2012
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 06/25/2012 01:11 PM, bearophile wrote:

 monarch_dodra:


 What bothers me is that it was my understanding that the D
 language standard protected me from this kind of undefined
 behavior. I did make use of anything unsafe, so what gives?
 Compiler not catch it but should have?


 Currently the compiler doesn't track where is located the memory of
 dynamic array slices. In general it's hard to perform this analysis, so
 I think the D compiler isn't supposed to catch all such bugs.

 On the other hand a certain amount of logic to statically detect simple
 cases like this one should be added. Maybe you want to add this as a
 Bugzilla enhancement request. If you have a strong C++ background you
 may even be able to write a patch in GitHub that implements a basic form
 of such static analysis.

 Regarding  safe, it can't help you here. Since day 0 I've said  safe is
 a named wrongly, because it just refers to a narrow definition of memory
 safety, that doesn't include the class of bugs discussed here.

 Bye,
 bearophile


It does. It is not fully implemented.
Jun 25 2012
parent reply "monarch_dodra" <monarch_dodra gmail.com> writes:
On Monday, 25 June 2012 at 12:01:22 UTC, Timon Gehr wrote:

 On 06/25/2012 01:11 PM, bearophile wrote:

 It does. It is not fully implemented.


Ok. That's good to know then. Thanks.

Out of sheer curiosity, if I have "potentially dangerous code, eg"

int[] fun(int i)
{
       int[3] statictab;
       int[]  = statictab
       if(i) dyntab = new int[3];;
       return dyntab;
}


I expect my compiler to refuse to compile this, because this 
*could* produce undefined behavior. Is this correct?
Jun 26 2012
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 06/26/2012 01:22 PM, monarch_dodra wrote:

 On Monday, 25 June 2012 at 12:01:22 UTC, Timon Gehr wrote:

 On 06/25/2012 01:11 PM, bearophile wrote:

 It does. It is not fully implemented.


 Ok. That's good to know then. Thanks.

 Out of sheer curiosity, if I have "potentially dangerous code, eg"

 int[] fun(int i)
 {
       int[3] statictab;
       int[] dyntab = statictab; // [fixed]
       if(i) dyntab = new int[3];;
       return dyntab;
 }


 I expect my compiler to refuse to compile this, because this *could*
 produce undefined behavior. Is this correct?


Yes, the code snipped should be refused in  safe code.
Jun 26 2012