GCC 3.3 release criteria

[Gabriel Dos Reis]

Richard Earnshaw <rearnsha@arm.com> writes:

| > | We have to be fairly careful here, since we are dealing with 3 different 
| > | specifications of "inline": GNU (pre-c99), C99 and C++.  I'm not 
| > | particularly familiar with the subtleties of all three.
| > | 
| > | C99 says (6.7.4par5):
| > | 
| > |  ... Making a function an inline function suggests that calls to the
| > |  function be as fast as possible.  The extent to which such suggestions are
| > |  effective is implementation defined.
| > | 
| > | Note two things.  Firstly, this is only a "suggestion".  Secondly, since 
| > | an implementation is free to ignore such a request any code that relies on 
| > | honouring the request for correct behaviour must be ill-formed.
| > 
| > then, do we plan to issue a diagnostic?
| 
| There are a lot of ill-formed (note I don't use other terms like 
| undefined) programs for which it is impossible to emit a diagnostic.

The reason I was asking is that, by default, if a program is nominated
"ill-formed" then a diagnostic is required unless that nomiation is
followed by the mention "no diagnostic is required".  My question was not
meant to imply that I was actively proposing to issue diagnostic (or the
contrary), but merely to query your position on that matter.

[...]

| > To extend my original comment, here are pieaces where C99 blesses ODR
| > violation:
| > 
| > 6.7.4/6
| >   [...] An inline definition does not provide an external definition
| >   for the function, and does not forbid an external definition in
| >   another translation unit.  An inline definition  provides an
| >   alternative to an external definition, which a translator may use to
| >   implement any call to the function  in  the  same translation  unit.
| >   It is unspecified whether a call to the function  uses  the  inline
| >   definition  or   the   external definition. 
| > 
| 
| I think that statement requires careful interpretation.  As I see it, the 
| intent is to make it clear that the inline definition only leads to an 
| external definition if a redeclaration with "extern" is provided.  It 
| doesn't, for example, permit a second compilation unit to provide a second 
| extern definition, or for separate compilation units to use different 
| definitions of the body of the inline function.  I do think it could have 
| said things more clearly though.

Well, that interpretation is  not that clear since that paragraph
specifically says the inline definition is an *alternative* to an
external definition.  Clearly, a second translation unit may provide
a (second) external definition.

| > I agree that ideally, C programs should not depend on inlining for
| > correctness, but in practice that seems to happen more than often.
| 
| In that we are not in disagreement.

OK.

-- Gaby