Independency of D from the C Standard Library

[burner]

An effort to decouple D from the C standard library.

[burner]

this is being worked on by Stefanos Baziotis during GSoC 2019

[wilzbach]

CC @baziotis

[baziotis]

At some point, I will add a more thorough description.

[dkgroot]

Adding a nice compatibility (wrapper) interface for memcpy in druntime with a clean d-implementation along side the libc-version is fantastic. Gaining all the niceties of dlang is great (bounds checking etc).

If the objective is to remove the c version (later on), that would not be such a good idea, imo. The amount of (libc) time that has been invested to support memcpy/memmove on every conceivable cpu/os/compiler combination, and having it optimized for unaligned access, sse2, very loose memory model cpu's etc, is not something that will/would be easy to replace. It would require considerable time/knowledge and effort now (impl) and in the future (maintenance) to do, without any real reward (AFAICT). Example: trying to implement a performant memmove on a loose memory model cpu like the (HP)Alpha is a daunting task with loads of pitfalls and hazards. (Please scrap this comment if the later is not the objective).

[JinShil]

If the objective is to remove the c version (later on), that would not be such a good idea

I believe I'm the one who originally proposed this project for the Symmetry Autumn of Code, so I'll speak to my original vision.

Bindings to the C standard library should not go anywhere; that is not the goal of this project. The goal of this project is to free the internal druntime implementations from depending directly on libc. druntime has a very weak dependency on libc. It only utilizes memcpy+friends and malloc+ friends; what I call "software building blocks". So, my initial premise is that libc is not sufficiently utilized to justify the dependency. Those building blocks can be written in D and free druntime from libc.

trying to implement a performant memmove on a loose memory model cpu like the (HP)Alpha is a daunting task with loads of pitfalls and hazards.

True. Not all platforms need to get on board. The D implementation could very easily just forward to libc's memcpy for those platfroms that don't have a proper optimized implementation (or even for all platforms at first). But at least the option will be available to provide a clean D implementation if they so choose. Also, it reduces the dependency D has on libc from an intrinsic hard dependency to a platform-dependent implementation detail.