[PATCH] D64939: Add a proposal for a libc project under the LLVM umbrella.

[Chandler Carruth via Phabricator via llvm-commits]

chandlerc added inline comments.


================
Comment at: llvm/docs/Proposals/LLVMLibC.rst:24
+- C17 and upwards conformant.
+- A modular libc with individual pieces implemented in the "as a
+  library" philosophy of the LLVM project.
----------------
MaskRay wrote:
> > "as a library" philosophy of the LLVM project.
> 
> This is not clear. See Szabolcs's concern in https://lists.llvm.org/pipermail/llvm-dev/2019-July/133894.html
> 
> It is a very good reply but many questions in that post have not been answered.
I don't know what it is you find not clear. I understand that many disagree with how LLVM's C++ libraries manage their API and ABI stability (or lack there-of), but I don't think that is a terribly relevant complaint towards this effort and so I don't know what specific technical concerns you think are still important to address here.

Unfortunately, the post you mentioned conflates technical critique with somewhat inflammatory comments. I think that rather than cite the post without elaboration, it would be useful to specifically articulate the concerns you still have so that they can be addressed.


================
Comment at: llvm/docs/Proposals/LLVMLibC.rst:29
+- Provide C symbols as specified by the standards, but take advantage
+  and use C++ language facilities for the core implementation.
+- Provides POSIX extensions on POSIX compliant platforms.
----------------
MaskRay wrote:
> Can you clarify a bit what features you really want from C++?
> 
> People have concerns that freestanding c++ language semantics are underspecified. My impression is that it may be useful in a few places, but in most places C will just be a better choice.
It's not clear that trying to split this hair *even more* finely is really useful in the absence of code.

I think if people can effectively leverage C++ language features when implementing runtime libraries, they should. And I don't think we need to try to preclude that before even seeing the usage.

LLVM's libunwind, libc++abi, the sanitizer runtimes, all have benefited from some limited use of C++ language features. Not sure what more evidence is really needed here...


================
Comment at: llvm/docs/Proposals/LLVMLibC.rst:59
+  make picking and choosing a straightforward task.
+- Most libc implementations break when built with sanitizer specific
+  compiler options. The llvm-libc will be developed from the start to
----------------
MaskRay wrote:
> > Most libc implementations break
> 
> "break" is not accurate. They just lack builtin sanitizer interceptors.
The folks developing the sanitizers seem to disagree somewhat?

Notably, hand written assembly and other extensions can easily prevent sanitizers from working at all.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64939/new/

https://reviews.llvm.org/D64939