This is the mail archive of the
mailing list for the GCC project.
Re: Questions about C as used/implemented in practice
- From: msebor at redhat dot com
- To: Peter dot Sewell at cl dot cam dot ac dot uk, Paul_Koning at dell dot com
- Cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Fri, 17 Apr 2015 10:03:21 -0600
- Subject: Re: Questions about C as used/implemented in practice
- Authentication-results: sourceware.org; auth=none
- References: <CAHWkzRS5Pfedgre-b93g1yfRT4CeMkEkm+qzok9DFwYGVVZSeg at mail dot gmail dot com> <43F29211-D9EA-48D5-BDED-38C2A7187202 at dell dot com> <CAHWkzRTmSJ9uZh8oT_9knCHe+-1QhyiOJmFwyKF4bSt=MK2jeA at mail dot gmail dot com>
- Reply-to: msebor at redhat dot com
On 04/17/2015 09:01 AM, Peter Sewell wrote:
On 17 April 2015 at 15:19, <Paul_Koning@dell.com> wrote:
On Apr 17, 2015, at 9:14 AM, Peter Sewell <Peter.Sewell@cl.cam.ac.uk> wrote:
Dear gcc list,
we are trying to clarify what behaviour of C implementations is
actually relied upon in modern practice, and what behaviour is
guaranteed by current mainstream implementations (these are quite
different from the ISO standards, and may differ in different
Iâm not sure what you mean by âguaranteedâ.
I suspect what the GCC team will say is guaranteed is âwhat the standard saysâ.
If that's really true, that will be interesting, but there may be
areas where (a) current implementation behaviour is stronger than what
the ISO standards require, and (b) important code relies on that
behaviour to such an extent that it becomes pragmatically infeasible
to change it. Such cases are part of what we're trying to discover
here. There are also cases where the ISO standards are unclear or
Implementations can and often do provide stronger guarantees than
the standards require. When the do, they must be documented in order
to be safely relied on. This is termed as implementation-defined
behavior in standards.
Standards may be unclear to casual readers but they must be consistent
and unambiguous. When they're not it's a defect that should be raised
If by âguaranteedâ you mean the behavior that happens to be implemented in a particular version of the compiler, that may well be different, as you said. But itâs also not particularly meaningful, because it is subject to change at any time subject to the constraints of the standard, and is likely to be different among different versions, and for that matter among different target architectures and of course optimization settings.
Some amount of variation has to be allowed, of course - in fact, what
we'd like to clarify is really the envelope of allowable variation,
and that will have to be parametric on at least some optimisation
All the questions in the survey that can be are answered are
answered without unambiguity in the C standard (either as well-
defined behavior - 4, 5, 11, 12, 15, unspecified - 1, 13, or
undefined - 2, 3, 7, 8, 9, 10, 14). There are no optimization
options that affect the answers.