@safe leak fix?

["Jérôme M. Berger"]

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.

	Cyclone has this neat notion that a pointer is associated to a 
memory "region" (by default, there are 3 regions: the data segment, 
the heap and the stack of the current function, but you can have 
user-defined regions). In this case, the function "foo" would have 
the type:

	@region (`R) T[] foo (@region (`R) T[] a)

where `R is an abstract region name meaning that the return value is 
in the same region as the argument. When compiling "bar", the 
compiler would then be able to see that it is returning a pointer to 
bar's stack region and refuse.

		Jerome
-- 
mailto:jeberger at free.fr
http://jeberger.free.fr
Jabber: jeberger at jabber.fr

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20091112/16d02eb4/attachment.pgp>