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