<div dir="ltr"><div dir="ltr">On Fri, Jul 12, 2019 at 9:15 AM David Greene via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Aaron Ballman via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="cremed">llvm-dev@lists.llvm.org</a>> writes:<br>
<br>
>> * Ability to layer this libc over the system libc.<br>
<br>
Echoing others, this seems dubious to me.  Why not build up small pieces<br>
at a time and write tests for them?  This library doesn't need to<br>
support all existing programs out of the gate.  </blockquote><div><br></div><div>I can *definitely* appreciate that not everybody wants a Frankenstein's-monster-of-a-library.</div><div><br></div><div>For what it's worth... for our usage (within Google, and specifically, within the production fleet), it is much more imperative to show broad usage sooner rather than later. It might make more sense from this perspective: we want to develop in the open (i.e., not just throw some code over the fence when we're "done enough"); and we want it to be of high enough quality that others might use it. In order to do this, we actually need to deliver the "low-hanging fruit" first, because that is a large part of what justifies the rest. Realities being what they are, it would be a non-starter to have no such facility; and it would be somewhat antithetical to carry out such a substantial part of our development effort behind closed doors.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I dont't think libc++<br>
layered on top of existing standard C++ libraries, so why would libc<br>
need to? </blockquote><div><br></div><div>There will almost certainly be other platforms where a top-to-bottom implementation would be impossible to implement. Not because of the libc parts, but functionality that -- for whatever reason -- is only available in a library that is also a libc.</div><div><br></div><div>(Examples off the top of my head: sandboxed environments, platforms which only allow syscalls through a provided DSO, or platforms which embed some critical functionality within the same binary blob as a vendor-provided libc.)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
>> * Provide C symbols as specified by the standards, but take advantage<br>
>> and use C++ language facilities for the core implementation.<br>
<br>
Does this mean C programs would require a C++ runtime?  If not, how will<br>
the project ensure that?<br></blockquote><div><br></div><div>Shooting from the hip: no. Turning off exceptions, RTTI, and static initializers (i.e., things which require a guard variable) is probably enough to obviate the need for the runtime.<br></div><div><br></div><div>Of course, this raises platform-specific concerns.</div></div></div>