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

[Florian Weimer <fweimer at redhat dot com>]

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