Ian Lance Taylor - Re: Clean up extern inline (original) (raw)

This is the mail archive of the gcc-patches@gcc.gnu.orgmailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

"Joseph S. Myers" joseph@codesourcery.com writes:

  • If we see an "extern inline" function:
    • If -fgnu-extern-inline is used, apply gnu89 semantics.
    • Else, if the declaration is in a system header, apply gnu89 semantics.
    • Else, if -std=c99 is used, but not -std=gnu99, issue an error.

I'd add that -fno-gnu-extern-inline should be an error in 4.1/4.2, and more generally in c89/gnu89 modes (the number of language dialects should be minimised). But adding any diagnostics for this to 4.1 branch would be a mistake; it would make upgrading from 4.1.2 to 4.1.3 unsafe for some users. (I don't think we should add such deprecation warnings to past release branches once they've had a release from them, at all, ever.)

I think this is a tough call. I thought about that issue as well. The problem is that every time we change semantics, people complain that we need to give them warning. And we are changing semantics in 4.3, and right now we aren't giving them any warning. And warning for just one release series--4.2.x--is simply not long enough.

These issues tend to be an uphill battle for me, but I really do feel strongly that we must warn for a minimum of two releases before we change fundamental behaviour. Of course I'm willing to be guided by majority feeling.

The rules (for 4.3 and later) should be:

Makes sense. Thanks.

Are you recommending that we name the option -fgnu89-extern-inline rather than -fgnu-extern-inline? I don't think we should have both option names, at any rate.

Ian

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]