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 like in C#/Java, while SafeD is "safe" only regarding a very specific thing (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 like in C#/Java, while SafeD is "safe" only regarding a very specific thing (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