fixincludes for glibc 'inline' non-C99 conformance

Steven Bosscher
Sat Nov 4 09:44:00 GMT 2006

On Saturday 04 November 2006 03:55, Mark Mitchell wrote:
> I'd still like to hear from other people about what they think the right
> path forward is.

IMHO the patch should stay in; the C99 semantics should be the
default; a switch should be provided to enable the old behavior. 
We should send out a message about this change of semantics on
gcc-announce (and maybe even other lists where affected users may
hang out).  We should also clearly document the differences between
GNU and C99 inline semantics.

It seems to me that at some point, we will want to have a compiler
that conforms to the ISO C99 standard by default.
We know that this will break existing code "out there" that relies
on the inverted GNU C semantics.  But that should not be a reason
to hold up the conversion, because there would be no incentive for
users to fix their code.
I think it's obvious that we shoud provide a flag to turn on the old
semantics for backward compatibility.  I understand Mike Stump's 
point of view about the switch, but just breaking things without
providing a switch to get back the old behavior is not acceptable.

On the other hand, if we switch C99 inline semantics on now, we have
to do everything we can to get that message out to the users who may
rely on the GNU inline semantics, or GCC 4.3 will break a lot of
existing code without warning.  I like Mike's idea to put a warning
in existing release branches.

Even in discussions on IRC, people have to actually look up what the
C99 semantics and GNU semantics are and how they differ.  We should
not expect our users to have access to the standards, and we also
should probably not ask of them that they understand all the gory
details.  To me, that means we should write down the differences in
the user manual to explain the differences and the implications for
the user.  Perhaps we can even write down a step-by-step plan for
the user to convert from GNU to C99 inline semantics.

It seems to me that this change breaking source compatibility is not
so different from what happened for GCC 3.4 when the new C++ parser
was contributed.  That also broke user code, but that didn't stop us
from making the change because standard conformance was more important
than backward compatibility.


More information about the Gcc-patches mailing list