[llvm-dev] A libc in LLVM

[Siva Chandra via llvm-dev]

On Wed, Jun 26, 2019 at 10:27 AM JF Bastien <jfbastien at apple.com> wrote:
>> 3. If there is a specification, we should follow it. The scope that we need includes most of the C Standard Library; POSIX additions; and some necessary, system-specific extensions. This does not mean we should (or can) follow the entire specification -- there will be some parts which simply aren't worth implementing, and some parts which cannot be safely used in modern coding practice.

> I’d love to hear what you have in mind with point 3 above, and see it expanded. libc++ implements C++11 and subsequent standards, and that makes me wonder:
>
> Which standards would this libc implement?

We need parts of the C standard library, parts of the POSIX
extensions, and also the linux headers. The community is of course
free to widen the surface as needed.

> Would you implement upcoming C standards, and how would you manage “experimental” features (API changes, ABI changes, etc)?

We will probably take this up on an as-needed basis.

> What parts of the standard wouldn’t you follow, why, how would the LLVM community determine this?

I would think what we (the "we" here is for the developer community
and not my company or my team) communicate would depend on how the
project evolves. For example, at the very beginning, we will probably
only say "large parts of the standards A, B, C are still
unimplemented." When the implemented surface becomes large enough, we
might start explicitly listing the unimplemented parts. There might be
parts which require qualification with version numbers.

> Which parts aren’t worth implementing?
> Which parts cannot be safely used in modern coding practice? How would you remedy what’s perceived as “the bad parts”?

At a certain level, what is worth and what is safe/unsafe is a
subjective matter. So, instead of listing my opinions here, let me say
this: If we build sufficient modularity into the libc, one will be
able to pick and choose what they want, and omit what they do not
want.

> I’d love it if the C Standards Committee, WG14, got renewed involvement through this project. Is that an explicit goal? Who will join WG14 in this effort?
> What part of C do you see this project help improve over time?

The answer to this question also depends on how the project and the
community around it evolves.

> How do you intend to test this C library? Fuzzing and all that is nice, but just straight conformance testing is what I’d like to hear about.

What kind of testing we want to do depends on what exactly is getting
tested. But in general, we want to do conformance tests for sure. We
also want to do some amount of differential testing between this new
libc and an existing, battle tested libc. Depending on what is getting
tested, we also want to be able to test against the test suite of an
existing libc.