[GSoC] 'Independency of D from the C Standard Library' progress and update thread

[Stefanos Baziotis]

On Saturday, 1 June 2019 at 22:45:40 UTC, sarn wrote:
>
> Do you mean you're planning to allow the stdlib's allocation 
> backend to be switched completely to libc-style malloc() and 
> free()

Currently, it is using malloc() and free(). Maybe you mean move 
away?

> or just that developers can always import core.stdc.stdlib and 
> call malloc() if they like?  (The second option won't be 
> enough.)

They will be able because libc is not going anywhere. The purpose 
is to create
an allocator _for the D Runtime_. Of course this allocator will 
be available
for users to use as well. It's just that the focus will be there.
Our initial plan was to make a D version of malloc() and free().
But, as Mike first suggested, we have the chance to create a more 
D-style
version allocator. And fortunately, the foundation has already 
been built
in std.experimental allocator.
And as a personal opinion, the interface of malloc() and free() 
is not ideal
for an allocator. From what I know, a lot of people working on 
allocators
seem to have the same opinion.
Just to disambiguate again, the purpose is that D Runtime won't 
depend on libc.

> One option is to design D's allocation so that users can link 
> with wrapped versions of tcmalloc, etc.  However, it's 
> important that this be designed properly so that it doesn't 
> require a custom compiler toolchain, otherwise it'll just be a 
> theoretical thing that no one actually does.  Preferably it 
> would work with LD_PRELOAD.
>

Well, the thing is to wrap an allocator, you first have to either 
write
the allocator in D, or create a dependency on that allocator.
Our choice is not the first, but somewhat the first. Meaning, I 
won't
port any allocator but the allocator I will write will of course 
be inspired
from work of others. Now, the important thing here is that I have 
so much time.
It's only a summer, which is not even completely devoted to the 
allocator (it's
about half the time). So, hopefully, either I or other people 
will continue
the work post-GSoC.

> I like the idea of moving beyond libc's API, but please 
> consider and test this use case.  A lot of smart people outside 
> D are working on allocators, and it would be a major 
> disadvantage if D can't use them.

As a I said, it will be able to use them. The purpose is not to 
replace them
in general, but specifically in the D Runtime.
Be sure to check again the starting post in this thread for why 
we're doing this,
and if there are any questions, please ask.

- Stefanos