GCC 3.3 release criteria

[Richard Earnshaw]

> | 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 
following, for example is ill-formed, though each statement is 
well-defined.

int x;
int plus_x() { x+=1; return x;}
int get_x() {return x;}
extern int f(int, int);
int g()
{ return g(plus_x(), get_x();}

In general, programmers just have to know how to avoid such constructs, 
since it is not generally possible for the compiler to diagnose them.
  
> 
> 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.

> 
> 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.

R.