This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On 06/14/2016 09:07 PM, Torvald Riegel wrote:
There are many cases of C files being included across all of glibc. Are there precise rules for when to pick .h vs. .c? pthread_cond_common.c doesn't have just declarations or small helper functions, so .c seemd to be the right choice.As far as I can tell, we use .c only if the file is *also* compiled as a C source file. In such cases, there are some preprocessor macros you can define to alter the behavior, before including the file. In other cases, it's used to create test cases with different compiler/linker flags (e.g., static linking). Or it's an override for the sysdeps mechanism.For example, have a look at these: posix/regex_internal.c
This file comes from gnulib and the symbols it defines need to be mangled by the preprocessor, hence the #include wrapper. A very special situation.
nss/nss_files/files-parse.c nss/getXXbyYY.c
These two files are used to implement something like an SML functor (or Ada generic package) with the help of the C preprocessor.
I believe pthread_cond_common.c is similar. It doesn't use the preprocessor to alter any behavior, but just uses C to provide commonly used functionality. It doesn't provide any functions that are just declarations, so something a C header would typically do.
We already have header files which contain inline functions, something that is quite natural.
If the functions are not expected to be inlined, you should put them in their own file, and declare them with attribute_hidden for PLT avoidance.
Thanks, Florian
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |