[llvm-dev] A libc in LLVM

[Siva Chandra via llvm-dev]

On Fri, Jun 28, 2019 at 9:29 AM JF Bastien <jfbastien at apple.com> wrote:
> Personally I’m really interested in a project that increases the quality of all C libraries, and of the C standard. I therefore think champions of this project signing up to collaborate with WG14 is important.
> Having this kind of champion is really important for an LLVM libc. I’m not sure I’d support such a project without such a person. As you come up with a plan, consider who that should be. Maybe it’s you :-)

When the need arises, I do not mind being a "champion" like this. To
begin with though, we (as in the team at Google I am representing) do
not intend to participate beyond what we already do (like the C++
committee). Let me point out that I said "to begin with". So,
depending on how things evolve, we might in future increase our
participation with the committees.

Personally, it feels like it is early days - before one goes to the
committee, they should first develop some experience implementing the
standard library. If there is already one such person in the
community, and they would like to take the lead and engage with the
committee from the start, it would be most welcome. I would only be a
hand-waving participant if I were to do it today.

> I think you need write a design for how this C library will be tested.
> You want a plan before it takes off. Testing standardized stuff has enough precedent that you should be able to look at what others have done, and come up with a plan up front. I really like that you want to fuzz, use sanitizers, etc. That’s pretty novel for this kind of project. Basic standards testing isn’t novel, so it should be pretty easy to figure out.

Beyond fuzz and sanitizer based testing, at a general level, this
would be covered:

1. Extensive unit testing.
2. Standards conformance testing.
3. If relevant and possible, differential testing: We want to be able
to test llvm-libc against another battle-tested libc. This is
essentially to understand how we differ from other libcs.
4. If relevant and possible, test against the testsuite of an existing
libc implementation.

One could go into details here, but I think it is best to take them up
on a case-by-case basis: when we are implementing X, we will discuss
what exact kind of testing makes sense for X.