search for: remalloc

On 01/08/2018 04:40 AM, David Chisnall via llvm-dev wrote: > On 26 Dec 2017, at 10:13, Bhatu via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> According to my understanding, it seems that the result of realloc will not technically alias the original pointer. When the realloc is done in-place the reference says: >> "The original pointer ptr is invalidated and any access

On 26 Dec 2017, at 10:13, Bhatu via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > According to my understanding, it seems that the result of realloc will not technically alias the original pointer. When the realloc is done in-place the reference says: > "The original pointer ptr is invalidated and any access to it is undefined behavior (even if reallocation was

Hello, According to my understanding, it seems that the result of realloc will not technically alias the original pointer. When the realloc is done in-place the reference <http://en.cppreference.com/w/c/memory/realloc> says: "The original pointer ptr is invalidated and any access to it is undefined behavior (even if reallocation was in-place)." Additionally from the C11 standard

..." the SEXP returned to R so that DATAPTR() points directly to the required address. - create a normal LISTSXP in the package, which holds a reference to all these objects, so that GC never takes place. - turn these objects read-only, or, at least, ensure that they are never free()d or remalloc()ed. overwriting the contents is not a critical issue. Would that approach work? Are there any alternative approaches? Any specific advice about turning these objects read-only? Thanks in advance.