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 10:03:25 -0700
Organization: None to speak of
Lines: 40
Message-ID: <lny43ba6xu.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> <8760qg5592.fsf@news.bourguet.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Info: mx02.eternal-september.org; posting-host="945944de09706c9b4e29b53c9d2efdc2"; logging-data="6885"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+390QqjADIvRJjUCH7R05a"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)
Cancel-Lock: sha1:qDWrsc543dy0SuH7FJ2c29fO7tI= sha1:eRCMFCCfWDcK7utGWM8qNnnUR/E=
Xref: csiph.com comp.lang.c:93060

Jean-Marc Bourguet <jm@bourguet.org> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> That's not how I interpret(ed) it.  Again, here's what the standard
>> says:
>>
>> N1570 6.7.3p7:
>>
>>      What constitutes an access to an object that has
>>      volatile-qualified type is implementation-defined.
>>
>> Perhaps it's poorly phrased (or perhaps I'm just reading it poorly),
>> but I've always understood that to mean that the implementation
>> defines what is or is not an access to a volatile object.
>
> Looking at the rationale, the intend seems to give room for the
> implementation to in the choice of the width of accessing instruction as
> well as in how to handle ++ and other cases where there is a read and a
> write between two sequencing points (is it one access with a read-write
> cycle or two accesses, one read and one write?).

I'm no longer convinced that there's any latitude in the treatment of ++
for volatile objects.  6.5.3.1p2 says:

    The expression ++E is equivalent to (E+=1).

and 6.5.16.2p3 says that E1 += 1 is equivalent to E1 = E1 + (E2), except
that lvalue of E1 is evaluated only once.

Given that 6.7.3p7 refers to what happens when an access occurs, rather
than what is or is not an access, I don't see any room for treating ++v
as a single access.  (The side effect of the two accesses, one read and
one write, are implementation-defined.)

Postfix ++ might be a little more complicated.

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