@safe leak fix?

grauzone none at example.net
Wed Nov 11 14:09:20 PST 2009


Walter Bright wrote:
> Consider the code:
> 
>   @safe:
>     T[] foo(T[] a) { return a; }
> 
>     T[] bar()
>     {
>         T[10] x;
>         return foo(x);
>     }
> 
> Now we've got an escaping reference to bar's stack. This is not memory 
> safe. But giving up slices is a heavy burden.
> 
> So it occurred to me that the same solution for closures can be used 
> here. If the address is taken of a stack variable in a safe function, 
> that variable is instead allocated on the heap. If a more advanced 
> compiler could prove that the address does not escape, it could be put 
> back on the stack.
> 
> The code will be a little slower, but it will be memory safe. This 
> change wouldn't be done in trusted or unsafe functions.

That's just idiotic. One of the main uses of static arrays is to _avoid_ 
heap memory allocation in the first place. Do what you want within 
@safe, but leave "unsafe" (oh god what a pejorative) alone.



More information about the Digitalmars-d mailing list