What should happen here?

[Johan]

On Monday, 20 September 2021 at 18:49:12 UTC, Steven 
Schveighoffer wrote:
>
> I feel like this might not necessarily be an issue, because 
> technically, you aren't using `c` any more, so it can be 
> deallocated immediately. But right in our documentation 
> [here](https://dlang.org/spec/interfaceToC.html#storage_allocation) it lists ways to alleviate this:
>
> ```
> If pointers to D garbage collector allocated memory are passed 
> to C functions, it's critical to ensure that the memory will 
> not be collected by the garbage collector before the C function 
> is done with it. This is accomplished by:
>
> * Making a copy of the data using core.stdc.stdlib.malloc() and 
> passing the copy instead.
> * Leaving a pointer to it on the stack (as a parameter or 
> automatic variable), as the garbage collector will scan the 
> stack.
> * Leaving a pointer to it in the static data segment, as the 
> garbage collector will scan the static data segment.
> * Registering the pointer with the garbage collector with the 
> std.gc.addRoot() or std.gc.addRange() calls.
> ```
>
> This to me seems like "leaving a pointer to it on the stack". 
> I'm not sure how else I would do that specifically? Plus, this 
> option is the only "free" one -- the others all require much 
> more complication. Adding a pointer to the stack is free. It's 
> just, I don't know how to tell the compiler to do that besides 
> declaring it.

First: the use of "stack" here is wrong and confusing. It should 
be "local storage" (notorious error throughout the spec). Indeed, 
what is done in your example is putting the pointer in local 
storage. The scope of that local storage is until the end of 
function scope (in your example). I don't think (in LDC) that we 
track the lifetime of variables in that way, so what is done is 
that the optimizer just looks at last point of use. This is 
similar to how Java behaves:
https://stackoverflow.com/questions/39285108/can-java-garbage-collect-variables-before-end-of-scope

As per language spec, the D compilers are non-compliant on this 
point. So a decision is needed to either change the language 
spec, or to complain with the D compilers to fix it.

-Johan