[llvm-dev] A libc in LLVM

Chandler Carruth via llvm-dev llvm-dev at lists.llvm.org
Tue Jun 25 15:39:31 PDT 2019


I'm gonna let the folks working on this respond to technical points, but
some meta points about discussion on this list...

On Tue, Jun 25, 2019 at 2:33 PM Rich Felker via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Since I have a little experience in this area, I'd like to chime in on
> it. :-) TL;DR I think it's a reall, REALLY bad idea.
>

In case there is any confusion, I'm really glad you're participating in the
discussion here because of this background.


> Second, corporate development teams are uniquely qualified to utterly
> botch a libc, yet still push it into widespread use, and the cost is
> painful compatibility hacks in all applications. Apple did this with
> their fork of BSD libc code. Google has done it once already with
> their fork of musl in Fuchsia


Let's keep this focused on technical issues and LLVM issues, none of the
above (or the text in this paragraph I've snipped out) has anything to do
with those, and I don't think the LLVM list is the right place to discuss
that.

LLVM has a long and effective history of both individuals and corporations
working effectively together in the open as part of the project. I don't
think this project poses any risk there, much like Zach points out in his
reply. Google is specifically discussing this early and trying to
participate in the open process of the LLVM community from the outset. =]

Also, I'd suggest using more specific technical language than "botch" and
"hacks" to make the discussion more productive.


With that, I'll wander off and let you all dig into the real issues here.
-Chandler
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190625/1e091462/attachment.html>


More information about the llvm-dev mailing list