This is the mail archive of the egcs@egcs.cygnus.com mailing list for the EGCS project. See the EGCS home page for more information.
> From: Joe Buck <jbuck@Synopsys.COM>
> To: leei@ai.sri.com (Lee Iverson)
> Date: Mon, 8 Feb 99 17:40:44 PST
> Cc: jbuck@Synopsys.COM, torvalds@transmeta.com, ross.s@ihug.co.nz,
> egcs@cygnus.com, hpa@transmeta.com
> It might be appropriate to generate an error, not a warning, if
> "extern inline" fails to inline, since it is clear from the
> documentation that this is not a mere hint.
No, it is not appropriate. First, from the doc:
The way to use it is to put a function definition in a header file
with these keywords, and put another copy of the definition (lacking
@code{inline} and @code{extern}) in a library file. The definition
in the header file will cause most calls to the function to be
inlined. If any uses of the function remain, they will refer to the
single copy in the library.
This clearly states that we expect some uses won't use the extern
inline, what would be the point of putting in a library definition if
we got errors on all translation units that didn't inline?
Second, we want forward compatibility with the next ANSI standard for
C, that in that standard, inline will be a pure hint (or if not that
one, in the one after it). An error message is a motion in the wrong
direction and a motion in the wrong direction is bad.