[libc-commits] [libc] [libc] implement pathconf/fpathconf (PR #87165)
Schrodinger ZHU Yifan via libc-commits
libc-commits at lists.llvm.org
Thu May 16 21:36:15 PDT 2024
SchrodingerZhu wrote:
Some general comments:
- A header file should either provide "prototype-only" function declarations (function signatures) or inline function definitions.
- If a function is prototype-only, there should be a translation unit that actually provide the implementation of such function. That is, there should be an accompany `.cpp` source file that will be compiled into an object file.
- When generating the final library/executables outputs, such object files will be collected together. Otherwise, you will get undefined-symbol errors.
- When compiling other source code using the header, the compiler does not "see" the definitions of functions. It just blindly trust you that you will provide such definitions properly.
- Inline function definitions is used if you want compilers to "see" the definitions, this will lead to more optimization opportunities.
- You should mark functions with definitions in header as `inline`. Notice that, for C/C++, the preprocessing of source files are really just "copy-and-paste". Therefore, if a function is not marked as `inline`, compilers will expose such symbols. Since the compiler cannot tell (not really but you can understand from this way) which parts come from header. Unfortunately, header files are subject to be reused by multiple source files. Therefore, such symbols will be repeatedly exposed in multiple objects. Normally, this will lead to multiple-definition errors.
- There are other ways to avoid multiple definitions such as `static` and unamed namespace. They basically tell the compiler that the symbol definition is local to the TU, such that the symbol shall not be exposed.
- In `llvm-libc`, our coding policy is to use `LIBC_INLINE` in header library.
https://github.com/llvm/llvm-project/pull/87165
More information about the libc-commits
mailing list