Path: csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Keith Thompson <kst-u@mib.org>
Newsgroups: comp.lang.c
Subject: Re: Default values in #define
Date: Thu, 01 Sep 2016 00:32:43 -0700
Organization: None to speak of
Lines: 33
Message-ID: <ln37lkaxd0.fsf@kst-u.example.com>
References: <d6e97054-1a68-418a-a6ae-5807ffccabbe@googlegroups.com> <lnoa4kfmkv.fsf@kst-u.example.com> <1d377167-a33a-402e-89ee-d3efa06d95ab@googlegroups.com> <87twebuwwn.fsf@gmail.com> <36a5bcc3-9e30-468c-a3e1-4b9c9788d395@googlegroups.com> <npjm5q$vho$1@dont-email.me> <1Kgvz.279$6d.174@fx26.iad> <npk7v8$p1c$1@dont-email.me> <8277ffd2-121d-4f3a-9bb0-ad3068696415@googlegroups.com> <nplahs$ngv$1@dont-email.me> <ee1434bc-5a52-4cea-91e3-432d67f2727c@googlegroups.com> <502669cd-f0fc-4b99-8c8a-0d806c8b5f20@googlegroups.com> <aa1be119-a537-4df5-97da-ade93afdba0c@googlegroups.com> <566c947b-91d6-43c1-86aa-772f6cf21e35@googlegroups.com> <nq1dfn$ola$1@dont-email.me> <ln8tvfczff.fsf@kst-u.example.com> <nq277p$4sb$1@dont-email.me> <lninujb133.fsf@kst-u.example.com> <kfnshtmp4nu.fsf@x-alumni2.alumni.caltech.edu> <lneg54c0dt.fsf@kst-u.example.com> <kfnoa48p4hs.fsf@x-alumni2.alumni.caltech.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Info: mx02.eternal-september.org; posting-host="945944de09706c9b4e29b53c9d2efdc2"; logging-data="28514"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18sh+R9Glo5IIM5IY23AJmz"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)
Cancel-Lock: sha1:Ysh7db8nLs8zRYjpDjTHSwaSCZY= sha1:H11Cbd+ejvqM4d1Utm0xe82Jqrs=
Xref: csiph.com comp.lang.c:93042

Tim Rentsch <txr@alumni.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
[...]
>> Perhaps the word "constitutes" is the problem?
>
> Yes, 6.7.3p7 is ambiguous by virtue of how "constitutes" is used:
> does it mean /what qualifies/ as a VQA, or does it mean /what
> actions will be used to carry out/ a VQA?  And I pretty much
> agree that the first of these (which corresponds to your initial
> interpretation) is an easier impression to get on a first
> reading, despite my belief that the second is what was intended.
> That is unfortunate and would be nice to address in a future
> revision.

To put it another way (more succinctly than my previous followup),
if the authors of the standard had *intended* to say that an
implementation gets to decide what is and is not an "access" to a
volatile object (and must document that choice), then the current
wording of 6.7.3p7:

    What constitutes an access to an object that has
    volatile-qualified type is implementation-defined.

would have been a clear and reasonable way to express that intent.
(Though it would have required some added or modified wording
elsewhere to make that consistent with the definition of "access"
and the semantics of "volatile".)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"