[libc-dev] API generation

[Petr Penzin via libc-dev]

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