[libc-dev] API generation
Petr Penzin via libc-dev
libc-dev at lists.llvm.org
Mon Nov 18 15:57:15 PST 2019
Hi,
I work on WebAssembly, and I was hoping we would eventually use LLVM
libc for end-to-end Wasm toolchain. I have some questions about "ground
truth" approach to libc API. I am sorry if those have been asked, could
not find the answers looking through mailing list messages and code reviews.
http://lists.llvm.org/pipermail/libc-dev/2019-October/000003.html
http://lists.llvm.org/pipermail/libc-dev/2019-October/000009.html
I was wondering what does API generation buy for the developers and
users. Maybe the question is how did previous implementations of libc
get away without generating headers, but also is API generation a
reasonable and foolproof solution.
Most importantly, the motivation seems to be that there are a few
potential standards a libc implementation needs to comply with. But how
many substantially different APIs are there realistically? If it is in
lower single digits, does this really make it worth the effort?
Secondly, libc API is not only types and function prototypes, it
typically includes depends on "feature test macros". I am not sure it is
possible to gracefully support those in a generated API. Encoding test
macros in API "ground truth" rules would make API rules as complex as C
macro code they are trying to replace. Leaving test macros up to the C
header files would result in a mix of preprocessor and rule logic which
would probably be more confusing than going all the way in either
(preprocessor or generation) direction.
Finally, somewhat rhetorical point on precedent and expertise. There is
enough precedent for a portable libc API written directly; likewise
C/C++ developers can understand and modify C headers without ramp-up -
not sure that can be said about tablegen. Writing header files is a
relatively simple part of the development process and there is a lot of
it happening inside and outside of LLVM.
Best,
Petr
More information about the libc-dev
mailing list