Mentions légales du service

Skip to content
Snippets Groups Projects
Commit cbc1007c authored by Jens Gustedt's avatar Jens Gustedt
Browse files

a short version of the DR for arithmetic on atomics

parent 38e30c80
No related branches found
No related tags found
No related merge requests found
Hide whitespace changes
Inline Side-by-side
gforge-p99/defects-and-improvements/n2059.html 0 → 100644
+ 232
− 0
View file @ cbc1007c
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<title>Minimal suggested corrigendum for arithmetic on atomic objects</title>
<style>
.quote {
background-color : #FFD;
text-align : left;
margin : 0em 2em;
}
.strike {
background-color : #FFD;
text-align : left;
text-decoration : line-through;
margin : 0em 2em;
}
.alternative {
background-color : #FCC;
text-align : left;
margin : 0em 2em;
}
pre {
background-color : #EEE;
text-style : sans-serif;
margin : 0em 2em;
}
code { background-color : #EEE; text-style : sans-serif }
</style>
</head>
<body>
<h2>Minimal suggested corrigendum for arithmetic on atomic objects</h2>
<p><br/>
<b>Submitter:</b> Jens Gustedt<br/>
<b>Submission Date:</b>
<!-- yyyy-mm-dd -->
2016-07-20 <br/>
<b>Reference Document: </b>n2059<br/>
<b>Version:</b> 1.0<br/>
<b>Date:</b> 2016-07-20<br/>
</p>
<p><b>Summary</b></p>
<p>
This is a follow up on document n1955 (DR 486) that revealed several
inconsistencies concerning the write up of arithmetic operations for
atomic types in the standard. For the sake of brevity I will not
repeat that discussion here, for the complete discussion please see
the <a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1955.htm">original
document</a>.
</p>
<p>
Already in the first document I proposed to act on these problems in
two steps.
</p>
<ul>
<li>Suggest a minimal corrigendum that can be included in the next
"bugfix" revision of the C standard</li>
<li>Continue the discussion for C2x
<ul><li>to extend the type generic functions
to more types</li>
<li>to eventually add other type generic functions for all
read-modify-write operators</li>
</ul>
</li>
</ul>
<p>
During discussion the committee found that the minimal corrigendum
that I suggested was already too intrusive such that it easily could
estimate the impact on the rest of the document. This document here
is an attempt to reduce that proposal even more to make changes that
merely obvious.
</p>
<p><b>Suggested Technical Corrigendum</b><br/></p>
<p><b>5.1.2.4 p5</b>, the text omits operators for the discussion as
synchronization operations. change the beginning:</p>
<p class="quote">
The <span class="strike">library defines</span> a number
of <span class="strike">atomic operations (7.17)</span> and
operations on mutexes (7.26.4) that are specially identified as
synchronization operations.
</p>
<p>to</p>
<p class="quote">
The <span class="alternative">language and the library define</span>
a number of <span class="alternative">operators (6.5) and type
generic functions (7.17) for atomic types</span> and operations on
mutexes (7.26.4) that are specially identified as synchronization
operations.
</p>
<p><b>6.2.6.1 p9</b>, replace:</p>
<p class="strike">
Loads and stores of objects with atomic types are done with
memory_order_seq_cst semantics.
</p>
<p>
by the following
</P>
<p class="alternative">
All operations that affect atomic objects that do not specify
otherwise have <code>memory_order_seq_cst</code> memory
consistency.
</p>
<p>
<b>7.17.7 p1</b>, the discussion omits operators and uses the term
"kind of operations" where it should simply speak of "type generic
function". Replace
</p>
<p class="quote">
There are only a few <span class="strike">kinds of operations on
atomic types, though there are many instances of those
kinds</span>. This subclause specifies each <span class="strike">general kind</span>.
</p>
<p>
by
</p>
<p class="quote">
<span class="alternative">In addition to the operators that are
defined for atomic objects,</span> there are a
few <span class="alternative">operations that are specified as type
generic functions</span>. This subclause specifies
each <span class="alternative">type generic function</span>.
</p>
<p>
<b>7.17.7.5</b> needs changes in p1, p3 and p5.
</p>
<p>
<b>p1</b>, this paragraph misses pointer types as valid
operands. Since only "add" and "sub" should be qualified for pointer
types, also add a mention which operations are valid. Change:
</p>
<p class="strike">
... to an object of any atomic integer type. None of these
operations is applicable to <code>atomic_bool</code>
</p>
<p>
to
</p>
<p class="alternative">
... to an object of any atomic integer or pointer type, as long as
the unqualified type is valid as left operand of the corresponding
operator <code>op=</code>.FOOTNOTE<br/> <br/>
FOOTNOTE: Thus these operations are not permitted for pointers to
atomic <code>_Bool</code>, and only "add" and "sub" variants are
permitted for atomic pointer types.
</p>
<p>
<b>p3</b> clarify "<em>no undefined</em>" by replacing:
</p>
<p class="quote">
For signed integer types, arithmetic is defined to use two’s
complement representation with silent wrap-around on overflow
<span class="strike">; there are no undefined
results</span>. For <span class="strike">address</span> types, the
result may be an <span class="strike">undefined address</span>, but
the operations otherwise have no <span class="strike">undefined
behavior</span>.
</p>
<p>by</p>
<p class="quote">
For signed integer types, arithmetic is defined to use two’s
complement representation with silent wrap-around on
overflow. <span class="alternative">If the corresponding operation
with identical values on the unqualified type is erroneous, the
result may not be a valid value</span>, but the operation otherwise
has no <span class="alternative">visible effect</span>.
</p>
<p>
<b>p5</b> is non-normative but factually wrong. Replace:
</p>
<p class="quote">
The only differences are that the <span class="strike">compound
assignment operators are not guaranteed to operate
atomically</span>, and the value yielded by a compound assignment
operator is the updated value of the object, whereas the value
returned by the atomic_fetch and modify generic functions is the
previous value of the atomic object.
</p>
<p>
by
</p>
<p class="quote">
The only differences are that
the <span class="alternative"><code>order</code> parameter may make
the memory consistency less strict
than <code>memory_order_seq_cst</code></span>, and the value yielded
by a compound assignment operator is the updated value of the
object, whereas the value returned by the atomic_fetch and modify
generic functions is the previous value of the atomic object.
</p>
<hr />
<!-- Entires below the line by WG14 only. -->
<p><br>
<a href="dr_4aa.htm">Previous Defect Report</a> &lt; - &gt;
<a href="dr_4bb.htm">Next Defect Report</a></p>
</body>
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment