memcpy, memset, memcmp and friends in the D Runtime

[Daniel Murphy]

"Mike"  wrote in message news:nxretodrkqizyiukwpze at forum.dlang.org...

> 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?

Ah.

> 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.

druntime and phobos both assume a c library is present, and this is a very 
safe assumption to make.

It's like assuming that bytes are 8 bits - you can certainly create 
platforms where this is true but those uses are not worth worrying about.

For a bare metal runtime that doesn't support C, it makes sense to only have 
a single runtime and add all the needed D and C runtime functions there.

So:
> It seems the D Runtime and Phobos also often make use of memcpy and 
> memset, but they do so through core.stdc which doesn't appear to be part 
> of the D Runtime.  Was this just a matter of convenience or thoughtful 
> design?  I'm guessing the former based on the fact that core.stdc is not 
> in the official language reference.

I don't think you can read that much into the lack of documentation.  I 
think it's a combination of "these are already documented on other sites" + 
"these are discourages" + "copying documentation has licensing issues".  The 
interface to the c library is a part of druntime and here to stay.

> * Were these methods intentionally omitted from the D Runtime, or just 
> taken for granted since they were so conveniently available in the C 
> standard library?

They were _not_ omitted from druntime, they were exposed though core.stdc. 
(and other places before that)
An implementation in druntime was not necessary because all platforms 
druntime targets provide a c runtime.

> * Should they be added to core.memory or some other module and exposed as 
> official, supported, methods of the D Runtime (hopefully changing their 
> names)?

No, they are already exposed via core.stdc.



So, if you want to support the full interface that druntime does, you will 
need to implement these functions somewhere.  There is no point in adding a 
second interface to them in upstream druntime.