This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GCC 3.3 release criteria
- From: Richard Earnshaw <rearnsha at arm dot com>
- To: Gabriel Dos Reis <gdr at integrable-solutions dot net>
- Cc: Richard dot Earnshaw at arm dot com, Steven Bosscher <s dot bosscher at student dot tudelft dot nl>, Franz Sirl <Franz dot Sirl-kernel at lauterbach dot com>, Daniel Jacobowitz <drow at mvista dot com>, Andi Kleen <ak at suse dot de>, "Kaveh R. Ghazi" <ghazi at caip dot rutgers dot edu>, gcc at gcc dot gnu dot org
- Date: Tue, 25 Feb 2003 14:44:47 +0000
- Subject: Re: GCC 3.3 release criteria
- Organization: ARM Ltd.
- Reply-to: Richard dot Earnshaw at arm dot com
> | 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.
>
> [...]
It's instructive to read the draft c99 rationale on this topic
http://wwwold.dkuug.dk/JTC1/SC22/WG14/www/docs/n897.pdf
They use the term "unspecified behaviour" which is probably the best one.
Unspecified behaviour can be "two or more possibilities" and the
implementation can chose any one on a case-by-case basis.
>
> | > 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.
Right, but it doesn't say that the definitions can be different; and it
doesn't allow two or more translation units to provide an extern
definition, even if they are identical. Again, the rationale seems to
clarify things significantly.
R.