druntime redesign

[Jacob Carlborg]

On 2020-05-06 13:42, Denis Feklushkin wrote:

> It is important to understand that libc library is not actually a 
> library for use C language.
> 
> Yes, it contains some C string and math functions, but OS API functions 
> what provided by libc is convient wrapper for OS syscalls what used by 
> everyone, because no one wants to support all number of OSes syscalls.

I'm not sure that I agree. I would say that libc is the library 
containing the functions and types defined by the C standard.

Then it just happens so that on most platforms they will bake in the OS 
APIs in the same library. I just checked, on macOS all programs are 
linked with libSystem. This is mostly an umbrella library that brings in 
other libraries. The library itself only contains 36 symbols, but it 
depends on 33 other libraries. One of them being libsystem_c, which 
seems to contain the actual C standard library. Then there's 
libsystem_kernel, which seems to contain the OS APIs.

> So, libc de facto is OS API.

That depends on the platform as well. On Linux the system calls provide 
a stable API. On macOS they don't. Apple explicitly specifies that the 
stable API is the syscall wrappers.

> It would be great to replace them. But this does not look as a priority, 
> because you can always use parts of any libc as a static library for 
> baremetal.

You cannot. glibc doesn't fully support static linking, not even on 
Linux. For example, DNS lookup does not work/is not fully supported in a 
fully statically linked binary.

> Perhaps it is better to wait for the "worldwide libc replacement" to 
> appear? Personally, I don't like the concept of errno in libc.

Yeah, I don't like it either.

-- 
/Jacob Carlborg