[Issue 12625] implicit slicing of RValue static array should be illegal (page 2)

https://issues.dlang.org/show_bug.cgi?id=12625 --- Comment #10 from Jonathan M Davis <issues.dlang@jmdavisProg.com> --- > What are the rules for temporaries that aren't further used in the expression? In this case, the result of foo isn't passed into another function, just a slice is. In C++, the temporary has to be valid until the end of the statement (which is by far the safest approach from what I can see), but I'm not sure that we've actually spec-ed it out to that level of detail in D. So, temporaries might disappear sooner (though I'm inclined to think that they shouldn't). Regardless, int[1] foo() { return [1]; } void main() { int[] a = foo(); } is essentially equivalent to int[1] foo() { return [1]; } void main() { int a* = &foo(); } and that doesn't compile even with @system. I'm 120% of the opinion that slicing a static array should _always_ be considered @system, and I really don't see much reason to make it any more legal to slice a temporary static array than it is to take its address. And isn't that pretty much what separates an lvalue and an rvalue - that the lvalue is guaranteed to have an address that can be assigned to, whereas an rvalue isn't guaranteed to have an address? By slicing a temporary static array, you're basically treating an rvalue like an lvalue, which is clearly bad. --

https://issues.dlang.org/show_bug.cgi?id=12625 --- Comment #11 from ZombineDev <petar.p.kirov@gmail.com> --- I don't think that it should be allowed even in @system code. I had a very ugly stack corruption because of this bug in a networking project. Thankfully, I had thorough unittests to catch it early, but still it wasn't obvious to track down at all. --

https://issues.dlang.org/show_bug.cgi?id=12625 --- Comment #12 from ZombineDev <petar.p.kirov@gmail.com> --- (In reply to ZombineDev from comment #11) > I don't think that it should be allowed even in @system code. I had a very ugly stack corruption because of this bug in a networking project. Thankfully, I had thorough unittests to catch it early, but still it wasn't obvious to track down at all. Just to clarify - I'm talking about OP case. Slicing static arrays in general can be @safe with enough escape analysis - e.g. when the slice doesn't outlive the slicee. --

https://issues.dlang.org/show_bug.cgi?id=12625 --- Comment #13 from Sobirari Muhomori <dfj1esp02@sneakemail.com> --- About return values: https://dlang.org/spec/function.html#function-return-values --

https://issues.dlang.org/show_bug.cgi?id=12625 --- Comment #14 from Jonathan M Davis <issues.dlang@jmdavisProg.com> --- (In reply to ZombineDev from comment #12) > Just to clarify - I'm talking about OP case. Slicing static arrays in general can be @safe with enough escape analysis - e.g. when the slice doesn't outlive the slicee. In theory, it colud be @safe in such a case, but the same can be said of taking the address of a local variable, which is currently always @system. The two cases are identical save for the fact that slicing a static array gives you a pointer and a size_t in a struct rather than just a naked pointer. So, they should be treated the same with regards to @safety and what types of operations are legal. If that means that we get escape analysis for both, then that's fine, but it would be inconsistent to do such escape analysis on the slicing of static arrays and not taking the address of a local variable. Regardless, barring the addition of such escape analysis, slicing a static array should _always_ be @system where it's legal at all. And this bug highlights a case where it shouldn't even be legal (and isn't legal with the equivalent code that involves taking the address of the temporary instead of slicing it). --

April 19, 2016

[Issue 12625] implicit slicing of RValue static array should be illegal

Posted by ZombineDev

Permalink

ZombineDev

Permalink

https://issues.dlang.org/show_bug.cgi?id=12625

--- Comment #16 from ZombineDev <petar.p.kirov@gmail.com> ---
(In reply to Jonathan M Davis from comment #14)
> (In reply to ZombineDev from comment #12)
> > Just to clarify - I'm talking about OP case. Slicing static arrays in general can be @safe with enough escape analysis - e.g. when the slice doesn't outlive the slicee.
> 
> In theory, it colud be @safe in such a case, but the same can be said of taking the address of a local variable, which is currently always @system. The two cases are identical save for the fact that slicing a static array gives you a pointer and a size_t in a struct rather than just a naked pointer. So, they should be treated the same with regards to @safety and what types of operations are legal. If that means that we get escape analysis for both, then that's fine, but it would be inconsistent to do such escape analysis on the slicing of static arrays and not taking the address of a local variable.

Yes, I agree. I meant escape analysis in general.

> Regardless, barring the addition of such escape analysis, slicing a static array should _always_ be @system where it's legal at all. And this bug highlights a case where it shouldn't even be legal (and isn't legal with the equivalent code that involves taking the address of the temporary instead of slicing it).

Yes, this OK as temporary solution. Unfortunately, it may be considered a huge breaking change for valid existing code, because it makes static arrays useless in @safe D.

--

https://issues.dlang.org/show_bug.cgi?id=12625 Nick Treleaven <ntrel-pub@mybtinternet.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://issues.dlang.org/sh | |ow_bug.cgi?id=8838 --

https://issues.dlang.org/show_bug.cgi?id=12625 Steven Schveighoffer <schveiguy@yahoo.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://issues.dlang.org/sh | |ow_bug.cgi?id=16519 --

Forums