Re: Handling of extern inline in c99 mode

[Mark Mitchell <mark at codesourcery dot com>]

Joseph S. Myers wrote:
> On Wed, 1 Nov 2006, Ian Lance Taylor wrote:
>
> > According to the proposal, we will restore the GNU handling for
> > "extern inline" even when using -std=c99, which will fix the problem
> > when using glibc.
>
> We definitely need to revert that until the fixincludes changes are 
> available.  (The precise nature of the fix - whether we disable the 
> inlines, change them to be C99-aware or add an attribute to give yet 
> another form of inline function in gnu99 mode that mimics gnu89 extern 
> inline - is less important.)

If we restore the previous behavior, then we don't need the fixincludes 
as immediately -- but since you're right that people will no doubt want 
to use GCC 4.4 with RHEL3, SLES8, etc., I think you're correct that when 
we do switch, we should be armed with fixincludes for GLIBC.  It's 
certainly not enough just to change the current GLIBC sourcebase to use 
C99 semantics going forward, as we must expect that people will want to 
install the software on older versions of the OS.

> Thus, I hereby propose starting the 48 hour reversion timer.

I concur.

> Once we have the fixincludes fixes, I don't think we need to wait for 4.4 
> to switch the default in gnu99 mode back to C99 inline semantics, as long 
> as we have those fixes during Stage 1.

I think it would be better to have GLIBC changed before changing the 
behavior of the compiler.  It might even be better to have a released 
version of GLIBC with the changes.  fixincludes causes sufficient 
problems for people that ensuring that only users putting new compilers 
on old systems suffer might be a good goal.

On the other hand, I agree that if we have fixincludes in place, then 
4.3 would not be in any way broken on GNU/Linux, so I think this is a 
judgment call.

--
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713