Can you find out where the code goes wrong?

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.

"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.

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

> 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.

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

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

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.

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