<HTML>
<STYLE>
 ins {text-decoration:none;font-weight:bold;background-color:#A0FFA0}
 del {text-decoration:line-through;background-color:#FFA0A0}
</STYLE>
<HEAD>
<TITLE>
Additional Core Language Issue Resolutions for Issaquah
</TITLE>
</HEAD>
<BODY>
<TABLE ALIGN="RIGHT" CELLSPACING="0" CELLPADDING="0">
 <TR><TD ALIGN="RIGHT" VALIGN="TOP"><B>Document:&#160;&#160;</B></TD><TD>WG21 N3914</TD></TR>
 <TR><TD ALIGN="RIGHT" VALIGN="TOP"><B>Author:&#160;&#160;&#160;</B></TD>
 <TD>William M. (Mike) Miller<BR/>Edison Design Group, Inc.</TD></TR>
 <TR><TD ALIGN="RIGHT"><B>Date:&#160;&#160;&#160;</B></TD><TD>2014-02-14</TD></TR>
</TABLE>

<BR/><BR/><BR/><BR/><BR/>

<P><H2>Additional Core Language Issue Resolutions for Issaquah</H2></P>

<P>The following issue resolutions, in addition to those in "ready"
and "tentatively ready" status in document
<A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3833.html">N3833</A>,
have been approved by the Core Language Working Group to be applied to the
DIS.</P>

<BR/><HR/><BR/>

<P><B><A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3833.html#1466">1466</A>. Visible sequences of side effects are redundant</B></P>

<P><B>Proposed resolution:</B></P>

<OL><LI><P>Change 1.10 [intro.multithread] paragraph 14 as follows:</P></LI>

<BLOCKQUOTE>

<del>The <I>visible sequence of side effects</I> on an atomic
object <I>M</I>, with respect to a value computation <I>B</I> of <I>M</I>,
is a maximal contiguous sub-sequence of side effects in the modification
order of M, where the first side effect is visible with respect
to <I>B</I>, and for every side effect, it is not the case that <I>B</I>
happens before it.</del> The value of an atomic object <I>M</I>, as
determined by evaluation <I>B</I>, shall be the value stored by
some <del>operation in the visible sequence of <I>M</I> with respect
to <I>B</I></del> <ins>side effect <I>A</I> that modifies <I>M</I>,
where <I>B</I> does not happen before <I>A</I></ins>. [<I>Note:</I> <del>It
can be shown that the visible sequence of side effects of a value
computation is unique given</del> <ins>The set of such side effects is also
restricted by the rest of the rules described here, and in particular,
by</ins> the coherence requirements below. &#8212;<I>end note</I>]

</BLOCKQUOTE>

<LI><P>Change 1.10 [intro.multithread] paragraph 20 as follows:</P></LI>

<BLOCKQUOTE>

[<I>Note:</I> The <del>visible sequence of side effects</del> <ins>value
observed by a load of an atomic</ins> depends on the &#8220;happens
before&#8221; relation, which depends on the values observed by loads of
atomics<del>, which we are restricting here</del>. The intended reading is
that there must exist an association of atomic loads with modifications
they observe that, together with suitably chosen modification orders and
the &#8220;happens before&#8221; relation derived as described above,
satisfy the resulting constraints as imposed here. &#8212;<I>end note</I>]

</BLOCKQUOTE>

<LI><P>Change 1.10 [intro.multithread] paragraph 22 as follows:</P></LI>

<BLOCKQUOTE>

[<I>Note:</I> Compiler transformations that introduce assignments to a
potentially shared memory location that would not be modified by the
abstract machine are generally precluded by this standard, since such an
assignment might overwrite another assignment by a different thread in
cases in which an abstract machine execution would not have encountered a
data race. This includes implementations of data member assignment that
overwrite adjacent members in separate memory locations. Reordering of
atomic loads in cases in which the atomics in question may alias is also
generally precluded, since this may violate the <del>&#8220;visible
sequence&#8221;</del> <ins>coherence</ins> rules. &#8212;<I>end note</I>]

</BLOCKQUOTE>

<LI><P>Change 29.3 [atomics.order] paragraph 3 as follows:</P></LI>

<BLOCKQUOTE>

<P>There shall be a single total order <I>S</I> on all
<TT>memory_order_seq_cst</TT> operations, consistent with the
&#8220;happens before&#8221; order and modification orders for all affected
locations, such that each <TT>memory_order_seq_cst</TT>
operation <I>B</I> that loads a value from an atomic object <I>M</I>
observes one of the following values:</P>

<UL><LI><P>the result of the last modification <I>A</I> of <I>M</I> that
precedes <I>B</I> in <I>S</I>, if it exists, or</P></LI>

<LI><P>if <I>A</I> exists, the result of some modification
of <I>M</I> <del>in the visible sequence of side effects with respect
to <I>B</I></del> that is not <TT>memory_order_seq_cst</TT> and that does not
happen before <I>A</I>, or</P></LI>

<LI><P>if <I>A</I> does not exist, the result of some modification
of <I>M</I> <del>in the visible sequence of side effects with respect
to <I>B</I></del> that is not <TT>memory_order_seq_cst</TT>.</P></LI>

</UL>

<P>[<I>Note:</I>...</P>

</BLOCKQUOTE>

</OL>

<BR/><HR/><BR/>

<P><B><A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3833.html#1673">1673</A>. Clarifying overload resolution for the second step of copy-initialization</B></P>

<P><B>Proposed resolution:</B></P>

<P>Change 13.3.3.1 [over.best.ics] paragraph 4 as follows:</P>

<BLOCKQUOTE>

<P>However, <del>when considering the argument of a constructor or
user-defined conversion function that is a candidate by 13.3.1.3
[over.match.ctor] when invoked for the copying/moving of the temporary in
the second step of a class copy-initialization, by 13.3.1.7
[over.match.list] when passing the initializer list as a single argument or
when the initializer list has exactly one element and a conversion to some
class <TT>X</TT> or reference to (possibly cv-qualified) <TT>X</TT> is
considered for the first parameter of a constructor of <TT>X</TT>, or by
13.3.1.4 [over.match.copy], 13.3.1.5 [over.match.conv], or 13.3.1.6
[over.match.ref] in all cases, only standard conversion sequences and
ellipsis conversion sequences are considered.</del> <ins>if the
target is</ins></P>

<UL><LI><P><ins>the first parameter of a constructor or</ins></P></LI>

<LI><P><ins>the implicit object parameter of a user-defined
conversion function</ins></P></LI>

</UL>

<P><ins>and the constructor or user-defined conversion function is a
candidate by</ins></P>

<UL><LI><P><ins>13.3.1.3 [over.match.ctor], when the argument is the
temporary in the second step of a class copy-initialization,</ins></P></LI>

<LI><P><ins>13.3.1.4 [over.match.copy], 13.3.1.5 [over.match.conv], or
13.3.1.6 [over.match.ref] (in all cases), or</ins></P></LI>

<LI><P><ins>the second phase of 13.3.1.7 [over.match.list] when the
initializer list has exactly one element, and the target is the first
parameter of a constructor of class <TT>X</TT>, and the conversion is
to <TT>X</TT> or reference to (possibly
cv-qualified) <TT>X</TT>,</ins></P></LI>

</UL>

<P><ins>user-defined conversion sequences are not considered.
[<I>Note:</I> These rules prevent more than one user-defined conversion
from being applied during overload resolution, thereby avoiding infinite
recursion. &#8212;<I>end note</I>] [<I>Example:</I></ins></P>

<PRE>
<ins>  struct Y { Y(int); };
  struct A { operator int(); };
  Y y1 = A();  //<SPAN style="font-family:Times;font-style:italic"> error: </SPAN>A::operator int()<SPAN style="font-family:Times;font-style:italic"> is not a candidate</SPAN>

  struct X { };
  struct B { operator X(); };
  B b;
  X x({b});    //<SPAN style="font-family:Times;font-style:italic"> error: </SPAN>B::operator X()<SPAN style="font-family:Times;font-style:italic"> is not a candidate</SPAN></ins>
</PRE>

<P><ins>&#8212<I>end example</I>]</ins></P>

</BLOCKQUOTE>

<BR/><HR/><BR/>

<P><B><A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3833.html#1759">1759</A>. UTF-8 code units in plain <TT>char</TT></B></P>

<P><B>Proposed resolution:</B></P>

<OL><LI><P>Change 2.14.5 [lex.string] paragraph 7 as follows:</P></LI>

<BLOCKQUOTE>

A string literal that begins with <TT>u8</TT>, such as <TT>u8"asdf"</TT>,
is a UTF-8 string literal <del>and is initialized with the given characters
as encoded in UTF-8</del>.

</BLOCKQUOTE>

<LI>Insert the following as a new paragraph following 2.14.5
[lex.string] paragraph 8:</LI>

<BLOCKQUOTE>

<ins>For a UTF-8 string literal, each successive element of the object
representation (3.9 [basic.types[) has the value of the corresponding
code unit of the UTF-8 encoding of the string.</ins>

</BLOCKQUOTE>

<LI><P>Change 3.9.1 [basic.fundamental] paragraph 1 as follows:</P></LI>

<BLOCKQUOTE>

...In any particular implementation, a plain <TT>char</TT> object can take
on either the same values as a <TT>signed char</TT> or an <TT>unsigned
char</TT>; which one is implementation-defined. <ins>For each value
<I>i</I> of type <TT>unsigned char</TT> in the range 0 to 255 inclusive,
there exists a value <I>j</I> of type <TT>char</TT> such that the result
of an integral conversion (4.7 [conv.integral]) from <I>i</I> to
<TT>char</TT> is <I>j</I>, and the result of an integral conversion from
<I>j</I> to <TT>unsigned char</TT> is <I>i</I>.</ins>

</BLOCKQUOTE>

</OL>

<BR/><HR/><BR/>

<P><B><A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3833.html#1786">1786</A>. Effect of merging allocations on memory leakage </B></P>

<P><B>Proposed resolution:</B></P>

<OL><LI><P>1. Change 5.3.4 [expr.new] paragraph 10 as follows:</P></LI>

<BLOCKQUOTE>

<P>An implementation is allowed to omit a call to a replaceable global
allocation function (18.6.1.1 [new.delete.single], 18.6.1.2
[new.delete.array]).  When it does so, the storage is instead provided by
the implementation or provided by extending the allocation of
another <I>new-expression</I>. The implementation may extend the allocation
of a <I>new-expression</I> <TT>e1</TT> to provide storage for
a <I>new-expression</I> <TT>e2</TT> if the <del>lifetime of the object
allocated by <TT>e1</TT> strictly contains the lifetime of the object
allocated by <TT>e2</TT>, <TT>e1</TT> and <TT>e2</TT> would invoke the same
replaceable global allocation function, and, for a throwing allocation
function, exceptions in <TT>e1</TT> and <TT>e2</TT> would be first caught
in the same handler.</del> <ins>following would be true were the
allocation not extended:</ins></P>

<UL><LI><P><ins>the evaluation of <TT>e1</TT> is sequenced before the
evaluation of <TT>e2</TT>, and</ins></P></LI>

<LI><P><ins><TT>e2</TT> is evaluated whenever <TT>e1</TT> obtains
storage, and</ins></P></LI>

<LI><P><ins>both <TT>e1</TT> and <TT>e2</TT> invoke the same
replaceable global allocation function, and</ins></P></LI>

<LI><P><ins>if the allocation function invoked by <TT>e1</TT> and
<TT>e2</TT> is throwing, any exceptions thrown in the evaluation of
either <TT>e1</TT> or <TT>e2</TT> would be first caught in the same
handler, and</ins></P></LI>

<LI><P><ins>the pointer values produced by <TT>e1</TT> and <TT>e2</TT>
are operands to evaluated <I>delete-expression</I>s, and</ins></P></LI>

<LI><P><ins>the evaluation of <TT>e2</TT> is sequenced before the
evaluation of the <I>delete-expression</I> whose operand is the
pointer value produced by <TT>e1</TT>.</ins></P></LI>

</UL>

<P><ins>[<I>Example:</I></ins></P>

<PRE>
<ins>  void mergeable(int x) {
    //<SPAN style="font-family:Times;font-style:italic"> These heap allocations are safe for merging:</SPAN>
    std::unique_ptr&lt;char[]&gt; a{new (std::nothrow) char[8]};
    std::unique_ptr&lt;char[]&gt; b{new (std::nothrow) char[8]};
    std::unique_ptr&lt;char[]&gt; c{new (std::nothrow) char[x]};

    g(a.get(), b.get(), c.get());
  }

  void unmergeable(int x) {
    std::unique_ptr&lt;char[]&gt; a{new char[8]};
    try {
      //<SPAN style="font-family:Times;font-style:italic"> Merging this allocation would change its catch handler.</SPAN>
       std::unique_ptr&lt;char[]&gt; b{new char[x]};
    } catch (const std::bad_alloc&amp; e) {
      std::cerr &lt;&lt; "Allocation failed: " &lt;&lt; e.what() &lt;&lt; std::endl;
      throw;
    }
  }</ins>
</PRE>

<P><ins>&#8212;<I>end example</I>]</ins></P>

</BLOCKQUOTE>

<LI><P>Change 5.3.5 [expr.delete] paragraph 7 as follows:</P></LI>

<BLOCKQUOTE>

<P>If the value of the operand of the <I>delete-expression</I> is not a null
pointer value, then:</P>

<UL><LI><P>If the allocation call for the <I>new-expression</I> for the
object to be deleted was not omitted <ins>and the allocation was not
extended</ins> (5.3.4 [expr.new]), the <I>delete-expression</I> shall call
a deallocation function (3.7.4.2 [basic.std.dynamic.deallocation]). The
value returned from the allocation call of the <I>new-expression</I> shall
be passed as the first argument to the deallocation function.</P></LI>

<LI><P><ins>Otherwise, if the allocation was extended or was provided by
extending the allocation of another <I>new-expression</I>, and the
<I>delete-expression</I> for every other pointer value produced by a
<I>new-expression</I> that had storage provided by the extended
<I>new-expression</I> has been evaluated, the <I>delete-expression</I>
shall call a deallocation function.  The value returned from the
allocation call of the extended <I>new-expression</I> shall be passed as
the first argument to the deallocation function.</ins></P></LI>

<LI><P>Otherwise, the <I>delete-expression</I> will not call a deallocation
function (3.7.4.2 [basic.std.dynamic.deallocation]).</P></LI>

</UL>

<P>Otherwise, it is unspecified whether the deallocation function will be
called. [<I>Note:</I>...</P>

</BLOCKQUOTE>

</OL>

<BR/><HR/><BR/>

<P><B><A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3833.html#1787">1787</A>. Uninitialized <TT>unsigned char</TT> values </B></P>

<P><B>Proposed resolution:</B></P>

<OL><LI><P>Change 3.3.2 [basic.scope.pdecl] paragraph 1 as follows:</P></LI>

<BLOCKQUOTE>

<P>The point of declaration for a name is immediately after its complete
declarator (Clause 8) and before its initializer (if any), except as noted
below. [<I>Example:</I></P>

<PRE>
  <del>int</del> <ins>unsigned char</ins> x = 12;
  { <del>int</del> <ins>unsigned char</ins> x = x; }
</PRE>

<P>Here the second <TT>x</TT> is initialized with its own (indeterminate)
value. &#8212;<I>end example</I>]</P>

</BLOCKQUOTE>

<LI><P>Change 4.1 [conv.lval] paragraph 2 as follows:</P></LI>

<BLOCKQUOTE>

<P>When an lvalue-to-rvalue conversion occurs in an unevaluated operand or
a subexpression thereof (Clause 5 [expr]) the value contained in the
referenced object is not accessed. In all other cases, the result of the
conversion is determined according to the following rules:</P>

<UL><LI><P>...</P></LI>

<LI><P><del>Otherwise, if <TT>T</TT> is a (possibly cv-qualified) unsigned
character type (3.9.1 [basic.fundamental]), and the object to which the
glvalue refers contains an indeterminate value (5.3.4 [expr.new], 8.5
[dcl.init], 12.6.2 [class.base.init]), and that object does not have
automatic storage duration or the glvalue was the operand of a
unary <TT>&amp;</TT> operator or it was bound to a reference, the result is
an unspecified value.<SUP>57</SUP></del></P></LI>

<LI><P><del>Otherwise, if the object to which the glvalue refers contains
an indeterminate value, the behavior is undefined.</del></P></LI>

<LI><P>Otherwise, the value contained in the object indicated by the
glvalue is the prvalue result.</P></LI>

</UL>

</BLOCKQUOTE>

<LI><P>Change 5.3.4 [expr.new] paragraph 17 as follows:</P></LI>

<BLOCKQUOTE>

<P>A <I>new-expression</I> that creates an object of type <TT>T</TT>
initializes that object as follows:</P>

<UL><LI><P>If the <I>new-initializer</I> is omitted, the object is
default-initialized (8.5 [dcl.init])<del>; if</del><ins>.  [<I>Note:</I>
If</ins> no initialization is performed, the object has <ins>an</ins>
indeterminate value. <ins>&#8212;<I>end note</I>]</ins></P></LI>

<LI><P>Otherwise, the <I>new-initializer</I> is...</P></LI>

</UL>

</BLOCKQUOTE>

<LI><P>Change 8.5 [dcl.init] paragraph 12 as follows:</P></LI>

<BLOCKQUOTE>

If no initializer is specified for an object, the object is
default-initialized<del>; if no initialization is performed,</del>.
<ins>When storage for</ins> an object with automatic or dynamic storage
duration <ins>is obtained, the object</ins> has <del>indeterminate
value</del> <ins>an <I>indeterminate value</I>, and if no initialization is
performed for the object, that object retains an indeterminate value until
that value is replaced (5.17 [expr.ass])</ins>. [<I>Note:</I> Objects with
static or thread storage duration are zero-initialized, see 3.6.2
[basic.start.init]. &#8212;<I>end note</I>] <ins>If an indeterminate
value is produced by an evaluation, the behavior is undefined except in
the following cases:</ins>

<UL><LI><P><ins>If an indeterminate value of unsigned narrow character type
(3.9.1 [basic.fundamental]) is produced by the evaluation
of:</ins></P></LI>

<UL><LI><P><ins>the second or third operand of a conditional
expression (5.16 [expr.cond]),</ins></P></LI>

<LI><P><ins>the right operand of a comma (5.18 [expr.comma]),</ins></P></LI>

<LI><P><ins>the operand of a cast or conversion to an unsigned narrow
character type (4.7 [conv.integral], 5.2.3 [expr.type.conv], 5.2.9
[expr.static.cast], 5.4 [expr.cast]), or</ins></P></LI>

<LI><P><ins>a discarded-value expression (Clause 5 [expr]),</ins></P></LI>

</UL>

<P><ins>then the result of the operation is an indeterminate value.</ins></P>

<LI><P><ins>If an indeterminate value of unsigned narrow character type
(3.9.1 [basic.fundamental]) is produced by the evaluation of the right
operand of a simple assignment operator (5.17 [expr.ass]) whose first
operand is an lvalue of unsigned narrow character type, an indeterminate
value replaces the value of the object referred to by the left
operand.</ins></P></LI>

<LI><P><ins>If an indeterminate value of unsigned narrow character type
(3.9.1 [basic.fundamental]) is produced by the evaluation of the
initialization expression when initializing an object of unsigned
narrow character type, that object is initialized to an indeterminate
value.</ins></P></LI>

</UL>

<P><ins>[<I>Example:</I></ins></P>

<PRE>
<ins>  int f(bool b) {
    unsigned char c;
    unsigned char d = c; //<SPAN style="font-family:Times;font-style:italic"> OK, </SPAN>d<SPAN style="font-family:Times;font-style:italic"> has an indeterminate value</SPAN>
    int e = d;           //<SPAN style="font-family:Times;font-style:italic"> undefined behavior</SPAN>
    return b ? d : 0;    //<SPAN style="font-family:Times;font-style:italic"> undefined behavior if </SPAN>b<SPAN style="font-family:Times;font-style:italic"> is </SPAN>true
  }</ins>
</PRE>

<P><ins>&#8212;<I>end example</I>]</ins></P>

</BLOCKQUOTE>

<LI><P>Change 12.6.2 [class.base.init] paragraph 8 as follows:</P></LI>

<BLOCKQUOTE>

...An attempt to initialize more than one non-static data member of a union
renders the program ill-formed. <ins>[<I>Note:</I></ins> After the call to
a constructor for class <TT>X</TT> <ins>for an object with automatic or
dynamic storage duration</ins> has completed, if <ins>the constructor was
not invoked as part of value-initialization and</ins> a member
of <TT>X</TT> is neither initialized nor given a value during execution of
the <I>compound-statement</I> of the body of the constructor, the member
has <ins>an</ins> indeterminate value. <ins>&#8212;<I>end note</I>]</ins>
[<I>Example:</I>...

</BLOCKQUOTE>

</OL>

<BR/><HR/><BR/>

</BODY>
</HTML>
