December 19, 2018 core.memory.GC allocation functions are not marked as @safe | ||||
---|---|---|---|---|
| ||||
Hello, everybody. While working at [this PR](https://github.com/dlang/phobos/pull/6811/files), reviews are welcome :D, I noticed that none of the `core.memory.GC` allocation functions are marked as `@safe`. I believe that `GC.malloc`, `GC.calloc`, `GC.qalloc` and `GC.expand` should all be `@safe`, as they either give you the **fresh** memory that you requested, or they fail. What are your thoughts on this? Cheers, Edi |
December 19, 2018 Re: core.memory.GC allocation functions are not marked as @safe | ||||
---|---|---|---|---|
| ||||
Posted in reply to Eduard Staniloiu | On 12/19/18 8:18 AM, Eduard Staniloiu wrote:
> Hello, everybody.
>
> While working at [this PR](https://github.com/dlang/phobos/pull/6811/files), reviews are welcome :D, I noticed that none of the `core.memory.GC` allocation functions are marked as `@safe`.
>
> I believe that `GC.malloc`, `GC.calloc`, `GC.qalloc` and `GC.expand` should all be `@safe`, as they either give you the **fresh** memory that you requested, or they fail.
>
> What are your thoughts on this?
malloc, calloc, qalloc and expand should all be safe (the first three are all different APIs to the same core feature anyway). realloc and free are obviously not.
There are actually a lot of functions in there that should be @safe. For instance getAttr, or getSize.
One key thing is not so much that it gives you fresh memory, but that it also does not leave dangling pointers.
To do this *right*, what is needed is to first mark the extern(C) functions @safe, in both the prototype and the implementation, and then add @trusted escapes where necessary in the implementation. Second, you can then change the GC struct wrapper functions to @safe.
-Steve
|
Copyright © 1999-2021 by the D Language Foundation