Re: [PATCH v2] Consolidate pthread_attr value validation

[Roland McGrath <roland at hack dot frob dot com>]

> > There's no need for always_inline.  If for some reason the compiler
> > decided not to, let it.  Declaring with "inline" does the same job as
> > __attribute__ ((unused)) for warning-suppression, so plain 'static
> > inline' is fine for inlines defined in (internal) headers.
> 
> You had said that we should avoid using inline alone and wherever
> absolutely necessary, use it along with
> __attribute__((always_inline)).

This is not a case of "absolutely necessary".  The only such cases are
where the code would be incorrect if not inlined; I think we have such
cases in the dynamic linker, for example.  

The cases here are simply optimization choices.  Those should be left to
the compiler.  'inline' is a hint to the compiler about optimization
choice, though from the GCC documentation it's not clear to me it really
makes any difference in practice at -O2, but clear that it doesn't make any
difference at -O3.  Hence it's clear that 'inline' should never be used in
.c files.  That was the context of the previous discussion but I don't
think we were clear about the distinction between cases in .c files and
cases in .h files.

'inline' also suppresses "defined but not used" warnings, and is less
typing than '__attribute__ ((unused))' for that purpose.  This is why I
said it might make sense to use it in .h files.  That is, I'm not sure we
need a hard and fast rule about always using '__attribute__ ((unused))' in
preference to 'inline' in .h files.  For simplicity and consistency of the
style, probably it makes to recommend just one or the other and stick to
that.  For normal .h files (as opposed to special-purpose things like
dynamic-link.h et al), a function should only be declared 'static' in a .h
file if it's the expectation that it will usually be inlined, so 'inline'
for that purpose makes sense to me.  I don't have a strong preference
between the two, nor do I really care that all uses be consistent across
all our normal .h files.  But for the purpose of having clear style
guidance for the project, I think we should choose one of the two to
recommend on the wiki and for reviewers to ask for consistency.  What I do
feel strongly is that we should not have normal .h files that elicit
warnings when used in new places, which is what happens when plain 'static'
appears in .h files.


Thanks,
Roland