[llvm-dev] A libc in LLVM

[Zachary Turner via llvm-dev]

On Tue, Jun 25, 2019 at 2:34 PM Rich Felker via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>
> On Tue, Jun 25, 2019 at 03:24:04AM +0000, Siva Chandra via llvm-dev wrote:
>
> Third, there is tremendous value in non-monoculture of libc
> implementations, or implementations of any important library
> interfaces or language runtimes. Likewise there's tremendous value in
> non-monoculture of tooling (compilers, linkers, etc.). Avoiding
> monoculture preserves the motivation for consensus-based standards
> processes rather than single-party control (see also: Chrome and what
> it's done to the web) and the motivation for people writing software
> to write to the standards rather than to a particular implementation.
> A big part of making that possible is clear delineation of roles
> between parts of the toolchain and runtime, with well-defined
> interface boundaries. Some folks have told me that I should press LLVM
> to make musl the "LLVM libc" instead of whatever Google wants to do,
> but that misses the point: there *shouldn't be* a "LLVM libc", or any
> one library implementation that's "first class" for use with LLVM
> while others are only "second class".
Doesn't having additional libc implementations to choose from
contribute *to* the ideal of not having a monoculture?

Also, I didn't read the proposal as segregating the world into first
class and second class libc implementations.  For example, libc++
currently works fine with non LLVM-based toolchains, and libstdc++
currently works fine with LLVM-based toolchains.  Do you see libc as
fundamentally different in this regard?


Regarding your second point, if Google were to write a libc
implementation and then upstream it in bulk, I would agree with you.
But being done in the open appears to solve the exact problem you are
concerned about, which is that corporate interests will lead to
lasting design decisions that aren't in the best interest of the
general public.  By doing it in the open, such problems can be
addressed before the code is ever committed.