Replacing C's memcpy with a D implementation

Walter Bright newshound2 at digitalmars.com
Mon Jun 11 08:00:10 UTC 2018


On 6/10/2018 8:43 PM, Mike Franklin wrote:
> That only addresses the @safe attribute, and that code is much too complex for 
> anyone to audit it and certify it as safe.
> 
> Exceptions are also not all handled, so there is no way it can pass as nothrow.
> 
> The runtime call needs to be replaced with a template that can take advantage of 
> D's compile-time type information instead of `TypeInfo`, but doing so will force 
> the implementation through semantic processing, which, in it's current state, 
> will fail to compile.  It needs to be refactored, and creating @safe, nothrow, 
> pure building blocks will help with that, hence the topic of this thread.

Making it a template is not really necessary. The compiler knows if there is the 
possibility of it throwing based on the type, it doesn't need to infer it.

(I notice it is doing __doPostblit(). This looks wrong, D allows data to be 
moved. As far as I can tell with a perfunctory examination, that's the only "can 
throw" bit.)

Doing without TypeInfo is a worthy goal most of the time, but I don't think it 
is of much value here because it calls the garbage collector anyway which 
requires TypeInfo.

Some obvious refactoring tasks for it would be to:

1. eliminate the gotos
2. use single assignment for variables
3. minimize the scopes of variables
4. use const
5. document the inputs and outputs
6. add test cases for the red lines


More information about the Digitalmars-d mailing list