Thread overview
GC-safe memory copying for D
Mar 02, 2012
Denis Shelomovskij
Mar 02, 2012
Robert Jacques
Mar 02, 2012
Denis Shelomovskij
March 02, 2012
Even `memcpy` is claimed dangerous at http://dlang.org/garbage.html
(because of possibility of moving GC, I suppose) but it just creates false positives for GC. `memmove` can even temporary destroy pointers in some overlapping cases like Google answer on "Lucky" `memmove source code` request does.

So I reinvented the wheel and created GC-safe `memmove` analog called `copyOverlapped` with comprehensive unittest coverage:
https://bitbucket.org/denis_sh/misc/src/tip/memutils.d

And I want this or such function to be included in druntime and be used in Phobos because using `memcpy`/`memmove` when even `memcpy` is called dangerous in docs looks incorrect and easily fixable.

P.S.
This post is inspired by bearophile's unanswered post titled  "Regarding a recent copy() fix" about really mysterious David Simcha's answer about `memmove`
http://d.puremagic.com/issues/show_bug.cgi?id=7484#c2
March 02, 2012
On Fri, 02 Mar 2012 08:13:00 -0600, Denis Shelomovskij <verylonglogin.reg@gmail.com> wrote:

> Even `memcpy` is claimed dangerous at http://dlang.org/garbage.html
> (because of possibility of moving GC, I suppose) but it just creates false positives for GC. `memmove` can even temporary destroy pointers in some overlapping cases like Google answer on "Lucky" `memmove source code` request does.
>
> So I reinvented the wheel and created GC-safe `memmove` analog called `copyOverlapped` with comprehensive unittest coverage:
> https://bitbucket.org/denis_sh/misc/src/tip/memutils.d
>
> And I want this or such function to be included in druntime and be used in Phobos because using `memcpy`/`memmove` when even `memcpy` is called dangerous in docs looks incorrect and easily fixable.
>
> P.S.
> This post is inspired by bearophile's unanswered post titled  "Regarding a recent copy() fix" about really mysterious David Simcha's answer about `memmove`
> http://d.puremagic.com/issues/show_bug.cgi?id=7484#c2

Is this CTFE compatible?
March 02, 2012
On 02-03-2012 16:25, Robert Jacques wrote:
> On Fri, 02 Mar 2012 08:13:00 -0600, Denis Shelomovskij
> <verylonglogin.reg@gmail.com> wrote:
>
>> Even `memcpy` is claimed dangerous at http://dlang.org/garbage.html
>> (because of possibility of moving GC, I suppose) but it just creates
>> false positives for GC. `memmove` can even temporary destroy pointers
>> in some overlapping cases like Google answer on "Lucky" `memmove
>> source code` request does.
>>
>> So I reinvented the wheel and created GC-safe `memmove` analog called
>> `copyOverlapped` with comprehensive unittest coverage:
>> https://bitbucket.org/denis_sh/misc/src/tip/memutils.d
>>
>> And I want this or such function to be included in druntime and be
>> used in Phobos because using `memcpy`/`memmove` when even `memcpy` is
>> called dangerous in docs looks incorrect and easily fixable.
>>
>> P.S.
>> This post is inspired by bearophile's unanswered post titled
>> "Regarding a recent copy() fix" about really mysterious David Simcha's
>> answer about `memmove`
>> http://d.puremagic.com/issues/show_bug.cgi?id=7484#c2
>
> Is this CTFE compatible?

Nope. It uses inline asm.

-- 
- Alex
March 02, 2012
02.03.2012 19:29, Alex Rønne Petersen пишет:
> On 02-03-2012 16:25, Robert Jacques wrote:
>> On Fri, 02 Mar 2012 08:13:00 -0600, Denis Shelomovskij
>> <verylonglogin.reg@gmail.com> wrote:
>>
>>> Even `memcpy` is claimed dangerous at http://dlang.org/garbage.html
>>> (because of possibility of moving GC, I suppose) but it just creates
>>> false positives for GC. `memmove` can even temporary destroy pointers
>>> in some overlapping cases like Google answer on "Lucky" `memmove
>>> source code` request does.
>>>
>>> So I reinvented the wheel and created GC-safe `memmove` analog called
>>> `copyOverlapped` with comprehensive unittest coverage:
>>> https://bitbucket.org/denis_sh/misc/src/tip/memutils.d
>>>
>>> And I want this or such function to be included in druntime and be
>>> used in Phobos because using `memcpy`/`memmove` when even `memcpy` is
>>> called dangerous in docs looks incorrect and easily fixable.
>>>
>>> P.S.
>>> This post is inspired by bearophile's unanswered post titled
>>> "Regarding a recent copy() fix" about really mysterious David Simcha's
>>> answer about `memmove`
>>> http://d.puremagic.com/issues/show_bug.cgi?id=7484#c2
>>
>> Is this CTFE compatible?
>
> Nope. It uses inline asm.
>

But one can add if(!__ctfe) before inline assembler to make it CTFE-able (in theory, not tested).

And a better way is to add if(__ctfe) block at the beginning of a function with simple byte-by-byte copying (forward or backward) not to compile both asm and regular logic code.