[libc-commits] [PATCH] D69421: [libc] Header generation scheme.

Alex Brachet via Phabricator via libc-commits libc-commits at lists.llvm.org
Fri Oct 25 15:24:52 PDT 2019


abrachet marked an inline comment as done.
abrachet added inline comments.


================
Comment at: libc/spec/stdc.td:1
+include "spec/spec.td"
+
----------------
sivachandra wrote:
> MaskRay wrote:
> > Can you explain a bit more why we need a header generator?
> > 
> > If you want to make some declarations condition on feature macros, I think the usual approach is:
> > 
> > ```
> > int foo(int);
> > int bar(int);
> > 
> > #if defined(_BSD_SOURCE) || defined(_XOPEN_SOURCE)
> > int qux(int);
> > #endif
> > ```
> Yes, that is how current implementations do it. While it is not necessarily bad, we want to avoid such patterns as much as possible so that we do not end up with the macro mess that current libcs ended up having. If you always generate, neither the sources, nor the generated headers have the macro mess. More importantly though, generating headers serves the use case of being able to selectively pick and choose what one wants to expose on their platform. Down stream configs become easier to manage.
FWIW I don’t think conditionally exposing function definitions with the *_SOURCE  macros is really a macro mess, it’s a pretty common practice among most (all?) libcs.

How far does this picking and choosing go? Would I be able to choose not to have the `qux` symbol in my libc.so at all? If so then it would be pretty bad to have it in the header at all even if it’s behind _GNU_SOURCE or similar I think.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69421





More information about the libc-commits mailing list