This is the mail archive of the
mailing list for the GCC project.
Re: Questions about C as used/implemented in practice
- From: Peter Sewell <Peter dot Sewell at cl dot cam dot ac dot uk>
- To: msebor at redhat dot com
- Cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>, Kayvan Memarian <Kayvan dot Memarian at cl dot cam dot ac dot uk>
- Date: Fri, 17 Apr 2015 17:54:48 +0100
- 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> <55312EC9 dot 50602 at redhat dot com>
- Reply-to: Peter dot Sewell at cl dot cam dot ac dot uk
On 17 April 2015 at 17:03, <firstname.lastname@example.org> wrote:
> 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>
>>>> 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
>> 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
>> internally inconsistent.
> 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.
The cases where the ISO standard explicitly identifies
implementation-defined behaviour are generally unproblematic.
The cases we're asking about, on the other hand, are typically cases
which ISO declares to be undefined behaviour (sometimes for historical
reasons relating to now-obsolete implementations) but where some code
does depend on particular implementation behaviour. We are trying to
identify and bound those cases.
> 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
> against them.
Yes, that's true - and we have in the past worked with the C++ and C
standards committees, to fix inconsistencies in the concurrency model.
But more than that, standards (including any implementation-specific
documentation) and common practice have to be sufficiently in sync
that the two work together: the former should give strong enough
guarantees to support normal usage, and implementations should be
sound with respect to them. For some aspects of C, we are currently
quite some way from that.
>>> 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).
We are really not asking about what the ISO standard says, but rather
about what can be and what is relied upon in practice. (That said,
our reading of the standard differs on several of those points.)
> There are no optimization
> options that affect the answers.