memory safety checks and trust

[aliak]

On Tuesday, 14 April 2020 at 12:32:18 UTC, Steven Schveighoffer 
wrote:
> On 4/14/20 5:56 AM, Walter Bright wrote:
>> On 4/13/2020 2:03 AM, Timon Gehr wrote:
>>>> Consider:
>>>>
>>>>    @system int* pumpkin(int i) { return &i; }
>>>>
>>>> Should that give an error or not?
>>>> ...
>>>
>>> I don't see why not.
>> 
>> I've written code like that to get the stack pointer value.
>
> Can't you use inline assembly?

You can cast at least:

ptrdiff_t f(int i) { return cast(ptrdiff_t)&i; }

Also,

I tried annotating that with @safe but it didn't work. What's the 
danger of casting the address of a variable to an integer type 
thing?

(I know that I can use @trusted as a work around)

>
>> 
>> As to the other case, to my mind putting the address of a 
>> stack local into a GC allocated object is highly suspicious:
>> 
>> 1. it is very very easy to do it unintentionally
>> 
>> 2. GC objects tend to be intended to outlast a function, yet

GC objects are a matter of convenience and safety and are using 
within function scopes all the time.

>> the stack address will not, so why is this a GC allocated 
>> object, as opposed to, say, an RAII object or even a stack 
>> allocated object?
>
> Because the stack doesn't provide a high limit of data space, 
> and RAII may not be what you want to use. In @system code, you 
> should be free to shoot yourself in the foot, and also to 
> correctly write memory safe code knowing where memory will stop 
> being accessed.
>
> -Steve

Another reason, you may not know how big your array is and need 
to rely on the GC (or manual memory management but the GC is just 
much more easier and safer to use)