memcpy, memset, memcmp and friends in the D Runtime

[Brad Anderson]

On Wednesday, 9 April 2014 at 12:38:20 UTC, monarch_dodra wrote:
> On Wednesday, 9 April 2014 at 12:12:35 UTC, Mike wrote:
>> On Wednesday, 9 April 2014 at 11:50:13 UTC, Daniel Murphy 
>> wrote:
>>> "Mike"  wrote in message 
>>> news:iflykgpsrmdbfhuwzqtp at forum.dlang.org...
>>>
>>>> So, my question remains:  If I'm porting D to a platform 
>>>> that has no C library, shouldn't a public, supported 
>>>> function that copies memory be added in the D Runtime?
>>>
>>> What platform doesn't have a C library?  And you can always 
>>> cast arrays to ubyte[] before assigning to avoid postblit.
>>
>> My custom, bare-metal, D-only platform has no C library, nor 
>> will it ever.  And, Yes, I know I can cast, but should I?
>>
>> memcpy is used quite often in Phobos.  Here's a small sample 
>> from std.array:
>>
>> void trustedMemcopy(T[] dest, T[] src) @trusted
>> {
>>    assert(src.length == dest.length);
>>    if (!__ctfe)
>>        memcpy(dest.ptr, src.ptr, src.length * T.sizeof);
>>    else
>>    {
>>        dest[] = src[];
>>    }
>> }
>>
>> You could ask the same question there, "Why isn't a cast used 
>> instead?" and remove the dependency on the C library.
>>
>> So far, it seems D has only been used on one subset of 
>> computer systems that happen to have a C library, but some of 
>> us our trying to break some new ground with D.  I'm 
>> challenging the "D is only useful on PCs with a C library" 
>> bias and looking to see if D has the will to stand on its own 
>> two feet instead of leaning on C.
>
> I think arguably, there should be D equivalents of the C 
> runtime functions, if only for the added safety of slices (for 
> example, memchr could be 100% certifiably safe), and to avoid 
> the rampant deduplication of things as in the above, because of 
> CTFE.
>
> These may or may not use the C-runtime library. But at that 
> point, it would become a "druntime implementation detail", 
> rather than rampant usage throughout phobos.

This list of secure alternatives to C functions Microsoft has 
would probably be a good source of inspiration when deciding what 
functions should be considered for reimplementation:

http://msdn.microsoft.com/en-us/library/wd3wzwts.aspx%7C%7Clist