www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Can you find out where the code goes wrong?

reply davidl <davidl nospam.org> writes:
import std.stdio;

string func()
{
	string s="abc";
	return s;
}

void func1()
{
	writefln("func1");
	string v = func();
	writefln("call func");
	writefln(func2());
}

byte[] func2()
{
	writefln("hello!");
	byte[16] v= [65,65,65,65,
		     65,65,65,65,
		     65,65,65,65,
		     65,65,65,65];
	writefln(v[0..16]);
	return v[0..16];
}

void main(string[] args)
{
	func1();
}

The culprit is the on stack array.

Should the compiler warn on slicing on a fixed length array? or even give  
an error?
I find this use case can easily go wrong! You may even think this code is  
correct at the very first glance.
May 24 2009
next sibling parent "Lionello Lunesu" <lionello lunesu.remove.com> writes:
"davidl" <davidl nospam.org> wrote in message 
news:op.uugvg5ahj5j59l my-tomato...
[snip]

 The culprit is the on stack array.

 Should the compiler warn on slicing on a fixed length array? or even give 
 an error?
 I find this use case can easily go wrong! You may even think this code is 
 correct at the very first glance.


Definately a bug. You should file it to bugzilla.

When returning the original stack-allocated array the compiler correctly 
complains:

test.d(25): Error: escaping reference to local v

but as soon as you slice it, even "v[]", it is no longer detected.

Good catch!

L.
May 24 2009
prev sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Sun, 24 May 2009 23:47:19 -0400, davidl <davidl nospam.org> wrote:


 import std.stdio;

 string func()
 {
 	string s="abc";
 	return s;
 }

 void func1()
 {
 	writefln("func1");
 	string v = func();
 	writefln("call func");
 	writefln(func2());
 }

 byte[] func2()
 {
 	writefln("hello!");
 	byte[16] v= [65,65,65,65,
 		     65,65,65,65,
 		     65,65,65,65,
 		     65,65,65,65];
 	writefln(v[0..16]);
 	return v[0..16];
 }

 void main(string[] args)
 {
 	func1();
 }

 The culprit is the on stack array.

 Should the compiler warn on slicing on a fixed length array? or even  
 give an error?
 I find this use case can easily go wrong! You may even think this code  
 is correct at the very first glance.


This can't be detected at compile time without full escape analysis.

It is an issue that has been in D forever.  And they are hard to find, so  
it would be nice if it were flagged by the compiler, but I don't think  
it's going to happen anytime soon.

-Steve
May 26 2009
parent reply grauzone <none example.net> writes:
 This can't be detected at compile time without full escape analysis.


I just realized that this means that in SafeD, converting from static 
arrays to dynamic arrays / slices must be forbidden. That is, if SafeD 
is really meant to be more than a vaporware-joke.
May 26 2009
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
grauzone:

That is, if SafeD is really meant to be more than a vaporware-joke.<


The idea of SafeD is good, but I'd like the current idea to have a different
name, because if I see a name like SafeD I think about the rounded up safety

(and Walter doesn't seem interested in the other kinds of safeties that in the
last years language designers stress).

Bye,
bearophile
May 26 2009
parent grauzone <none example.net> writes:
bearophile wrote:

 grauzone:

 That is, if SafeD is really meant to be more than a vaporware-joke.<


 
 The idea of SafeD is good, but I'd like the current idea to have a different
name, because if I see a name like SafeD I think about the rounded up safety

(and Walter doesn't seem interested in the other kinds of safeties that in the
last years language designers stress).


You mean memory safety? The "other" safety can as well go into D 
directly, because it doesn't interfere with the goals of performance or 
system programming.

An example would be to introduce different kinds of casts: casts that 
are always safe (real-to-int, dynamic casts, ...), and casts that allow 
horrible (but sometimes needed) stuff like reinterpret casting pointers 
into integers.


 Bye,
 bearophile
May 26 2009
prev sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
grauzone wrote:

 That is, if SafeD
 is really meant to be more than a vaporware-joke.


It's currently implemented in D2 using the -safe switch, AFAIK
May 26 2009
parent reply Don <nospam nospam.com> writes:
Robert Fraser wrote:

 grauzone wrote:

 That is, if SafeD
 is really meant to be more than a vaporware-joke.


 
 It's currently implemented in D2 using the -safe switch, AFAIK


Currently it prevents you from using inline asm, but it doesn't stop you 
  from using pointers. So it's still 80% vapourware.
May 26 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Don wrote:

 Robert Fraser wrote:

 grauzone wrote:

 That is, if SafeD
 is really meant to be more than a vaporware-joke.


 It's currently implemented in D2 using the -safe switch, AFAIK


 
 Currently it prevents you from using inline asm, but it doesn't stop you 
  from using pointers. So it's still 80% vapourware.


It shouldn't stop one from using pointers as long as uses can be 
checked. (Many uses are checkable.)

It's hard to find a good balance between announcing planned features 
early so as they're open for discussion and ideas, and causing 
frustration around unimplemented ideas. Probably there's some erring on 
the side of being overenthusiastic about sharing information about stuff 
well before it's been implemented.


Andrei
May 26 2009
parent Don <nospam nospam.com> writes:
Andrei Alexandrescu wrote:

 Don wrote:

 Robert Fraser wrote:

 grauzone wrote:

 That is, if SafeD
 is really meant to be more than a vaporware-joke.


 It's currently implemented in D2 using the -safe switch, AFAIK


 Currently it prevents you from using inline asm, but it doesn't stop 
 you  from using pointers. So it's still 80% vapourware.


 
 It shouldn't stop one from using pointers as long as uses can be 
 checked. (Many uses are checkable.)
 
 It's hard to find a good balance between announcing planned features 
 early so as they're open for discussion and ideas, and causing 
 frustration around unimplemented ideas. Probably there's some erring on 
 the side of being overenthusiastic about sharing information about stuff 
 well before it's been implemented.


Well, there's been a fair number of easter eggs, too...
In the latest release, for example, 'writefln' and 'writeln' are 
magical: you can include them in a CTFE function without stopping it 
from executing at compile time. (They don't _do_ anything, but...).

I think it's impossible to avoid this situation in a language where the 
development process is so open and compiler releases are so frequent.
(and where Walter tries to do so much simultaneously <g>).
May 26 2009