Subject: Re: Challenging the deprecation of volatile compound statements
From: Michael Wong (fraggamuffin_at_[hidden])
Date: 2021-02-11 06:20:39
Thanks Paul for this analysis. Copying Wouter in case he does not have SG14
On Thu, Feb 11, 2021 at 3:08 AM Paul M. Bendixen via SG14 <
> After a (long overdue) complete read of both r0 and r4 of p1152 i have
> come to a few conclusions:
> 1. While the motivation in r0 is quite thorough, it fails to convey
> the dangers of using the compound volatile operations in higher level
> highly threaded code that was alluded to in tonight's meeting.
> If anyone could enlighten me further in this regard I'd be much
> 2. The changes that Wouter and others (myself included) found
> frightening were mostly neglected in R0: "This is a departure from C
> which breaks source compatibility (once removed), but maintains ABI
> And even though the committee was heard on the question, the
> question was before SG1 and EWG ( from r0 -> r1 changelog), not
> necessarily parts of the committee that are affected by the proposed
> changes (compound operations).
> 3. The only change to the r4 paper that I can see would be necessary
> is in 3.7 item 9 where "op=" is discussed.
> I would posit that, put before SG14 the vote on "Deprecate volatile
> compound operations (including ++ and --) on scalar types (arithmetic,
> pointer, enumeration)." would have been a very different one and we
> might even revisit this at the next embedded themed SG14 meeting.
> The concerns regarding incorrect usage of the comppound operations is
> not as bad as they are made out to. It is even there in the standard
> right next to it:
> "The behavior of an expression of the form E1 op= E2 is equivalent to
> E1 = E1 op E2 except that E1 is evaluated only once"
> While the wording might be a bit clearer this explicitly states that
> it is the same. Examples regarding tearing in the parts of volatile
> that have been retained are also mentioned in the paper and as such I
> do not see the reason why this usage of volatile should be any more
> Regarding the concern of breaking functioning code expressed as code
> that must operate on variables that must be declared volatile that
> also has a controlled application of the compound operation, I find
> that it has not been very well examined and I am perplexed that the
> committee would break codebases for such a large part of the C++
> The paper even acknowledges the quite early retirement of volatile,
> with the, in my eyes, incorrect assumption:
> "Now that codebases use atomic and have moved away from erroneous
> volatile, we believe deprecation is warranted. In other words, what
> would have been a disastrous breaking change for C++11 is merely good
> house-cleaning for C++20." (from r0)
> Finally, on a more introspective note, this leaves me with some doubts
> regarding what we are doing here.
> This paper has its r0 date in 2018. I have been following this group
> since at least then and cannot remember it ever being mentioned before
> being part of the standard.
> If the purpose of this group is to be an outreach group and get the
> opinions of people who don't regularly attend standards meetings, then
> this paper becoming standard marks a failure on this point to me.
> We need to do better and I would like to hear from the rest of the
> group if you have any idea as to how.
> Before going too much into discussions on this, please read the two
> paper versions (that are actually different papers), they are well
> written and relatively short and having read through them will give
> you a better understanding of what is being discussed and will prevent
> others from having to tell you what is in them.
> Best Regards
> Paul M. Bendixen
> â¢ â â â¢/â¢ â/â¢ â¢ â/â¢ â â¢ â¢/â â¢ â¢ â¢/â¢/â â¢/â â¢ â¢/â¢ â¢/â â¢ â¢ â/â¢/â â¢/â¢ â â
> â¢â â¢/â â â¢/â â/â¢ â/â¢ â¢/â¢ â â¢ â¢/â¢ â â¢ â â¢ â/â â¢ â â¢/â â â/â â//
> SG14 mailing list
SG14 list run by firstname.lastname@example.org
Older Archives on Google Groups