Re: [RFA:] more glibc fixinclude adjustments for extern inline

[Bruce Korb <bkorb at gnu dot org>]

ChHans-Peter Nilsson wrote:
>> Date: Sat, 5 Jan 2008 12:48:32 +0100
>> From: "Richard Guenther" <richard.guenther@gmail.com>

> I'm not sure what to make of that difference.  Some theories:

> - Bug in fixincludes, appearing only with certain orders of the
>   fixes, causing spurious extraneous applications of fixes.
>   (Doesn't really explain the new "c++/4.3.0/parallel" fixes.)

The order of the files depends on the output of "find" and
that depends upon directory order.  Nevertheless, there is
no dependency on file order for fixincludes output.  Each
file is processed without any dependencies on what has gone
before.

> There is another problem that you pointed out on IRC, that I'd
> repeat here for the record: that the fix construct
> 
>> #ifdef __GNUC_GNU_INLINE__
>> extern
>> #endif
>> __inline int whatever ();
> 
> is brittle and will break if there's a separate "extern int
> whatever ()".  Instead appending (to the extern __inline) a
> __attribute__ ((__gnu_inline__)) helps, see below.  You probably
> won't notice for the glibc_c99_inline_4 fix, as there's no extra
> "extern" declaration there.  None I could see for glibc-2.3.6 at
> least.

That may/should be uncovered in a fixincludes test.  Though there is
no file-to-file dependency issue, there is certainly a fix-to-fix
dependency issue.  That is the main purpose of the "check" stuff.
If one fix changes something another fix was intended to work on,
then there is likely a problem.  "make check" is intended to
uncover these issues.

Cheers - Bruce