This is the mail archive of the 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]

Re: [PATCH] New condvar implementation that provides stronger ordering guarantees.

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

For example, have a look at these:

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.


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]