It seems that, D's array is strange,
It can implicit convert static arrays to dynamic arrays no error and no warning.
But when I return the converted arrays out the function.
Outside function will get some wrong data.

It may very easily cause some bug because no error when convert static arrays to dynamic arrays.

CODE:

import std.stdio;

void main()
{
	auto a1 = test11();
	auto a2 = test22();
	assert(a1==a2);
	writeln(a1);
	writeln(a2);
	getchar();
}

int[3] test1()
{
	int[3] arr;
	arr[0]=1;
	arr[1]=2;
	arr[2]=3;
	return arr;
}

int[] test11()
{
	return test1();
}

int[3] test2()
{
	int[3] arr;
	arr[0]=1;
	arr[1]=2;
	arr[2]=3;
	return arr;
}

int[] test22()
{
	return test2();
}

AlanThinker:

> It seems that, D's array is strange,
> It can implicit convert static arrays to dynamic arrays no error and no warning.
> But when I return the converted arrays out the function.
> Outside function will get some wrong data.
>
> It may very easily cause some bug because no error when convert static arrays to dynamic arrays.

Yeah, what do you suggest to change in the language to avoid this problem?

Bye,
bearophile

Is it possible to raise error when implicit convert static arrays to dynamic arrays?
Because there are really different.


On Sunday, 9 November 2014 at 10:04:16 UTC, bearophile wrote:
> AlanThinker:
>
>> It seems that, D's array is strange,
>> It can implicit convert static arrays to dynamic arrays no error and no warning.
>> But when I return the converted arrays out the function.
>> Outside function will get some wrong data.
>>
>> It may very easily cause some bug because no error when convert static arrays to dynamic arrays.
>
> Yeah, what do you suggest to change in the language to avoid this problem?
>
> Bye,
> bearophile

AlanThinker:

> Is it possible to raise error when implicit convert static arrays to dynamic arrays?
> Because there are really different.

To do this you need a sound tracking of memory areas. I think this is a "must have" for D, but so far D designers think otherwise.

If you just disallow that kind of operations indiscriminately, you reduce a lot the usefulness of D (because fixed size => dynamic slice array is a conversion useful in many cases) and probably force the introduction of many casts, and I don't know if this will increase the overall safety of the D code.

Bye,
bearophile

BTW, adding .dup resolve error:

int[] test11()
{
  return test1().dup;
}

int[] test22()
{
  return test2().dup;
}

int[3] test1()
{
  int[3] arr;
  ...
}

disasm shows:
- arr created on stack
- arr address returned
- stack changed
- data lost.

On Sun, 09 Nov 2014 12:46:28 +0000
novice2 via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> int[3] test1()
> {
>    int[3] arr;
>    ...
> }
> 
> disasm shows:
> - arr created on stack
> - arr address returned
> - stack changed
> - data lost.
hm. what i see in disasm is: array is created on the *caller* stack. then address of that array passed to `test1()` as hidden argument, so `test1()` actually returns nothing at all, it just changes that passed array.

> BTW, adding .dup resolve error:

BTW, adding .dup resolve error, but i mean it easy to make mistake because no compile error when implicit convert.

On Sun, Nov 09, 2014 at 08:29:58AM +0000, AlanThinker via Digitalmars-d wrote:
> It seems that, D's array is strange,
> It can implicit convert static arrays to dynamic arrays no error and
> no warning.
> But when I return the converted arrays out the function.
> Outside function will get some wrong data.
> 
> It may very easily cause some bug because no error when convert static arrays to dynamic arrays.
[...]

Yes, this is a known problem. There may even be an issue filed in bugzilla about it (if not, please file one!). The problem is that local static arrays are allocated on the stack, and the implicit conversion to dynamic array is simply taking a slice of the stack-allocated array. As a result, after the function returns, the slice is now pointing at stack memory that has gone out of scope.

I'm not sure if the current compiler issues a warning / error if you do this in @safe code, but IMO it should do this even in @system code since the implicit conversion is almost never correct.


T

-- 
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird. -- D. Knuth

On Sunday, 9 November 2014 at 15:09:10 UTC, H. S. Teoh via Digitalmars-d wrote:
> On Sun, Nov 09, 2014 at 08:29:58AM +0000, AlanThinker via Digitalmars-d wrote:
>> It seems that, D's array is strange,
>> It can implicit convert static arrays to dynamic arrays no error and
>> no warning.
>> But when I return the converted arrays out the function.
>> Outside function will get some wrong data.
>> 
>> It may very easily cause some bug because no error when convert static
>> arrays to dynamic arrays.
> [...]
>
> Yes, this is a known problem. There may even be an issue filed in
> bugzilla about it (if not, please file one!). The problem is that local
> static arrays are allocated on the stack, and the implicit conversion to
> dynamic array is simply taking a slice of the stack-allocated array. As
> a result, after the function returns, the slice is now pointing at stack
> memory that has gone out of scope.
>
> I'm not sure if the current compiler issues a warning / error if you do
> this in @safe code, but IMO it should do this even in @system code since
> the implicit conversion is almost never correct.
>
>
> T

The problem is, that you need to be able to take a slice of a stack-allocked array (otherwise stack allocated arrays are useless). Eg you should be able to pass a slice of a stack array to writefln().

Detecting if the slice is returned, requires flow analysis. Currently the front-end doesn't do any flow analysis at all, except for a couple of special cases like closures and super() calls.