Safely extend the size of a malloced memory block after realloc
Benjamin Thaut via Digitalmars-d
digitalmars-d at puremagic.com
Wed Aug 19 07:54:46 PDT 2015
On Wednesday, 19 August 2015 at 14:45:31 UTC, Steven
Schveighoffer wrote:
>
> In the case where the pointer changes, you are in trouble. The
> original memory is now free, which means it can be overwritten
> by something else (either the C heap or some other thread that
> reallocates it). Then if your GC runs *before* you have added
> the new memory, it may collect the now-no-longer-referred-to
> data. It's no different than your original situation.
>
> I actually think the case where the pointer changes is worse.
Yes I made the same observation in the meantime.
>
> Also, I note that others have said one can call GC.collect from
> another thread, which is true. One could call GC.enable as
> well. If you have concerns of this happening (i.e. you don't
> control all the code, and think your code may coexist with
> something that calls GC.collect), the likely correct mechanism
> is to take the GC global lock while doing your operation. I'm
> not sure if you can do that via the current API, you may have
> to add such a feature.
>
Yes I figured as much. The entire purpose of this thraed was to
point out that you can not safely forward a realloc to the GC.
Unfortunately its not a option not to use realloc as I'm binding
some code I don't have control over. To summarize the entire
issue and a possible solutions I created the following ticket:
https://issues.dlang.org/show_bug.cgi?id=14934
Kind Regards
Benjamin Thaut
More information about the Digitalmars-d
mailing list