<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
    "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<meta charset="utf-8">
<title>C++ Standard Library Priority 1 Issues Resolved Directly In Oulu</title>
<style type="text/css">
  p {text-align:justify}
  li {text-align:justify}
  blockquote.note
  {
    background-color:#E0E0E0;
    padding-left: 15px;
    padding-right: 15px;
    padding-top: 1px;
    padding-bottom: 1px;
  }
  ins {background-color:#A0FFA0}
  del {background-color:#FFA0A0}
  table {border-collapse: collapse;}
</style>
</head>
<body>
<h1>C++ Standard Library Priority 1 Issues Resolved Directly In Oulu</h1>
<table>
<tr>
<td align="left">Doc. no.</td>
<td align="left">P0397R0</td>
</tr>
<tr>
<td align="left">Date: 2016-06-24</td>
<td align="left"><p>Revised 2016-06-24 at 07:06:31 UTC</p>
</td>
</tr>
<tr>
<td align="left">Project:</td>
<td align="left">Programming Language C++</td>
</tr>
<tr>
<td align="left">Reply to:</td>
<td align="left">Alisdair Meredith &lt;<a href="mailto:lwgchair@gmail.com">lwgchair@gmail.com</a>&gt;</td>
</tr>
</table>
<h2>Immediate Issues</h2>
<hr>
<h3><a name="2687" href="#2687">2687.</a> <tt>{inclusive,exclusive}_scan</tt> misspecified</h3>
<p><b>Section:</b> 26.8.7 [exclusive.scan], 26.8.8 [inclusive.scan], 26.8.9 [transform.exclusive.scan], 26.8.10 [transform.inclusive.scan] <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Tim Song <b>Opened:</b> 2016-03-21 <b>Last modified:</b> 2016-06-24</p>
<p><b>Priority: </b>1
</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p>
When P0024R2 changed the description of <tt>{inclusive,exclusive}_scan</tt> (and the <tt>transform_</tt> version), 
it seems to have introduced an off-by-one error. Consider what N4582 26.8.8 [inclusive.scan]/2 says of 
<tt>inclusive_scan</tt>:
</p>
<blockquote>
<p>
Effects: Assigns through each iterator <tt>i</tt> in <tt>[result, result + (last - first))</tt> the value of
</p>
<ul>
<li><p>
<tt><i>GENERALIZED_NONCOMMUTATIVE_SUM</i>(binary_op, init, *j, ...)</tt> for every <tt>j</tt> in <tt>[first, first
+ (i - result))</tt> if <tt>init</tt> is provided, or
</p></li>
<li><p>
<tt><i>GENERALIZED_NONCOMMUTATIVE_SUM</i>(binary_op, *j, ...)</tt> for every <tt>j</tt> in <tt>[first, first + (i
- result))</tt> otherwise.
</p></li>
</ul>
</blockquote>
<p>
When <tt>i == result</tt>, <tt>i - result = 0</tt>, so the range <tt>[first, first + (i - result))</tt> is 
<tt>[first, first)</tt> &mdash; which is empty. Thus according to the specification, we should assign 
<tt><i>GENERALIZED_NONCOMMUTATIVE_SUM</i>(binary_op, init)</tt> if <tt>init</tt> is provided, or 
<tt><i>GENERALIZED_NONCOMMUTATIVE_SUM</i>(binary_op)</tt> otherwise, which doesn't seem "inclusive" &mdash; and isn't 
even defined in the second case.
<p/>
The parallelism TS's version uses <tt><i>GENERALIZED_NONCOMMUTATIVE_SUM</i>(binary_op, *first, ..., *(first + (i - result)))</tt> &mdash; 
which is a closed range, not a half-open one.
<p/>
Similar issues affect <tt>exclusive_scan</tt>, <tt>transform_inclusive_scan</tt>, and <tt>transform_exclusive_scan</tt>. 
</p>
<p><i>[2016-06 Oulu]</i></p>

<p>Voted to Ready 11-0 Tuesday evening in Oulu</p>


<p><b>Proposed resolution:</b></p>
<p>
This wording is relative to N4582.
</p>
<ol>
<li><p>Edit 26.8.7 [exclusive.scan]/2 as indicated:</p>
<blockquote class="note">
<p>
[<i>Drafting note</i>: when <tt>i</tt> is <tt>result</tt>, <tt>[first, first + (i - result))</tt> is an empty range, 
so the value to be assigned reduces to <tt><i>GENERALIZED_NONCOMMUTATIVE_SUM</i>(binary_op, init)</tt>, which is 
<tt>init</tt>, so there's no need to special case this.]
</p>
</blockquote>

<blockquote><pre>
template&lt;class InputIterator, class OutputIterator, class T, class BinaryOperation&gt;
  OutputIterator exclusive_scan(InputIterator first, InputIterator last,
                                OutputIterator result,
                                T init, BinaryOperation binary_op);
</pre>
<blockquote>
<p>
-2- <i>Effects</i>: Assigns through each iterator <tt>i</tt> in <tt>[result, result + (last - first))</tt> the value of
<ins><tt><i>GENERALIZED_NONCOMMUTATIVE_SUM</i>(binary_op, init, *j, ...)</tt> for every <tt>j</tt> in 
<tt>[first, first + (i - result))</tt>.</ins></p>
<ul>
<li><p>
<del><tt>init</tt>, if <tt>i</tt> is <tt>result</tt>, otherwise</del>
</p></li>
<li><p>
<del><tt><i>GENERALIZED_NONCOMMUTATIVE_SUM</i>(binary_op, init, *j, ...)</tt> for every <tt>j</tt> in <tt>[first, first
+ (i - result) - 1)</tt>.</del>
</p></li>
</ul>
</blockquote>
</blockquote>
</li>

<li><p>Edit 26.8.8 [inclusive.scan]/2 as indicated:</p>

<blockquote><pre>
template&lt;class InputIterator, class OutputIterator, class BinaryOperation&gt;
  OutputIterator inclusive_scan(InputIterator first, InputIterator last,
                                OutputIterator result,
                                BinaryOperation binary_op);
template&lt;class InputIterator, class OutputIterator, class BinaryOperation&gt;
  OutputIterator inclusive_scan(InputIterator first, InputIterator last,
                                OutputIterator result,
                                BinaryOperation binary_op, T init);
</pre>
<blockquote>
<p>
-2- <i>Effects</i>: Assigns through each iterator <tt>i</tt> in <tt>[result, result + (last - first))</tt> the value of
</p>
<ul>
<li><p>
<tt><i>GENERALIZED_NONCOMMUTATIVE_SUM</i>(binary_op, init, *j, ...)</tt> for every <tt>j</tt> in <tt>[first, first
+ (i - result <ins>+ 1</ins>))</tt> if <tt>init</tt> is provided, or
</p></li>
<li><p>
<tt><i>GENERALIZED_NONCOMMUTATIVE_SUM</i>(binary_op, *j, ...)</tt> for every <tt>j</tt> in <tt>[first, first
+ (i - result <ins>+ 1</ins>))</tt> otherwise.
</p></li>
</ul>
</blockquote>
</blockquote>
</li>

<li><p>Edit 26.8.9 [transform.exclusive.scan]/1 as indicated:</p>

<blockquote><pre>
template&lt;class InputIterator, class OutputIterator,
         class UnaryOperation,
         class T, class BinaryOperation&gt;
  OutputIterator transform_exclusive_scan(InputIterator first, InputIterator last,
                                          OutputIterator result,
                                          UnaryOperation unary_op,
                                          T init, BinaryOperation binary_op);
</pre>
<blockquote>
<p>
-1- <i>Effects</i>: Assigns through each iterator <tt>i</tt> in <tt>[result, result + (last - first))</tt> the value of
<ins><tt><i>GENERALIZED_NONCOMMUTATIVE_SUM</i>(binary_op, init, unary_op(*j), ...)</tt> for every <tt>j</tt> in 
<tt>[first, first + (i - result))</tt>.</ins></p>
<ul>
<li><p>
<del><tt>init</tt>, if <tt>i</tt> is <tt>result</tt>, otherwise</del>
</p></li>
<li><p>
<del><tt><i>GENERALIZED_NONCOMMUTATIVE_SUM</i>(binary_op, init, unary_op(*j), ...)</tt> for every <tt>j</tt> in 
<tt>[first, first + (i - result) - 1)</tt>.</del>
</p></li>
</ul>
</blockquote>
</blockquote>
</li>

<li><p>Edit 26.8.10 [transform.inclusive.scan]/1 as indicated:</p>

<blockquote><pre>
template&lt;class InputIterator, class OutputIterator,
         class UnaryOperation,
         class BinaryOperation&gt;
  OutputIterator transform_inclusive_scan(InputIterator first, InputIterator last,
                                          OutputIterator result,
                                          UnaryOperation unary_op,
                                          BinaryOperation binary_op);
template&lt;class InputIterator, class OutputIterator,
         class UnaryOperation,
         class BinaryOperation, class T&gt;
  OutputIterator transform_inclusive_scan(InputIterator first, InputIterator last,
                                          OutputIterator result,
                                          UnaryOperation unary_op,
                                          BinaryOperation binary_op, T init);
</pre>
<blockquote>
<p>
-1- <i>Effects</i>: Assigns through each iterator <tt>i</tt> in <tt>[result, result + (last - first))</tt> the value of
</p>
<ul>
<li><p>
<tt><i>GENERALIZED_NONCOMMUTATIVE_SUM</i>(binary_op, init, unary_op(*j), ...)</tt> for every <tt>j</tt> in <tt>[first, first
+ (i - result <ins>+ 1</ins>))</tt> if <tt>init</tt> is provided, or
</p></li>
<li><p>
<tt><i>GENERALIZED_NONCOMMUTATIVE_SUM</i>(binary_op, unary_op(*j), ...)</tt> for every <tt>j</tt> in <tt>[first, first
+ (i - result <ins>+ 1</ins>))</tt> otherwise.
</p></li>
</ul>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2704" href="#2704">2704.</a> <tt>recursive_directory_iterator</tt>'s members should require '<tt>*this</tt> is dereferenceable'</h3>
<p><b>Section:</b> 27.10.14.1 [rec.dir.itr.members], 27.10.13.1 [directory_iterator.members] <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Eric Fiselier <b>Opened:</b> 2016-05-08 <b>Last modified:</b> 2016-06-24</p>
<p><b>Priority: </b>1
</p>
<p><b>View other</b> <a href="lwg-index-open.html#rec.dir.itr.members">active issues</a> in [rec.dir.itr.members].</p>
<p><b>View all other</b> <a href="lwg-index.html#rec.dir.itr.members">issues</a> in [rec.dir.itr.members].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In 27.10.14.1 [rec.dir.itr.members] the following members are specified as having the requirement 
"<tt>*this != recursive_directory_iterator{}</tt>":
</p>
<ul>
<li><p><tt>options()</tt></p></li>
<li><p><tt>depth()</tt></p></li>
<li><p><tt>recursion_pending()</tt></p></li>
<li><p><tt>operator++</tt></p></li>
<li><p><tt>increment(...)</tt></p></li>
<li><p><tt>pop()</tt></p></li>
<li><p><tt>disable_recursion_pending()</tt></p></li>
</ul>
<p>
This requirement is not strong enough since it still allows non-dereferenceable iterators to invoke these methods. 
For example:
</p>
<blockquote><pre>
recursive_directory_iterator it(".");
recursive_directory_iterator it_copy(it);
assert(it_copy.depth() == 0); // OK
++it;
assert(it_copy.depth() == ???); // Not OK
auto x = *it_copy; // Is this OK?
</pre></blockquote>
<p>
I believe these should instead require that <tt>*this</tt> is dereferenceable, however the current specification 
seems to say that all previous copies of <tt>it</tt> are still dereferenceable although not what they dereference to.
<p/>
[class.directory_iterator] p4:
</p>
<blockquote class="note">
<p>
The result of <tt>operator*</tt> on an end iterator is undefined behavior. For any other iterator value a <tt>const 
recursive_directory_entry&amp;</tt> is returned. The result of <tt>operator-&gt;</tt> on an end iterator is 
undefined behavior. For any other iterator value a <tt>const directory_entry*</tt> is returned.
</p>
</blockquote>
<p>
Is the intention of this clause to make all non-end iterators dereferenceable?
<p/>
One further complication with these methods comes from the specification of <tt>recursive_directory_iterator</tt>'s 
copy/move constructors and assignment operators which specify the following post conditions:
</p>
<ul>
<li><p><tt>this-&gt;options() == rhs.options()</tt></p></li>
<li><p><tt>this-&gt;depth() == rhs.depth()</tt></p></li>
<li><p><tt>this-&gt;recursion_pending() == rhs.recursion_pending()</tt></p></li>
</ul>
<p>
If <tt>rhs</tt> is the end iterator these post conditions are poorly stated.
</p>

<p><i>[2016-06, Oulu &mdash; Daniel comments]</i></p>

<p>
The loss of information caused by bullet three of the suggested wording below is corrected by <a href="lwg-active.html#2726">2726</a>'s
wording.
</p>
<p>Voted to Ready 7-0 Monday morning in Oulu</p>


<p><b>Proposed resolution:</b></p>
<p>
This wording is relative to N4582.
</p>

<blockquote class="note">
<p>
[<i>Drafting note</i>: I have not attempted to fix the specification of the copy/move constructors and assignment 
operators for <tt>recursive_directory_iterator</tt>]</p>

<p>
[<i>Drafting note</i>: <tt>increment</tt> directly specifies "Effects: As specified by Input iterators (24.2.3)",
 so no additional specification is needed.]
</p>
</blockquote>

<ol>
<li><p>Change 27.10.13 [class.directory_iterator] p4 as indicated:</p>


<blockquote><p>
-4- <del>The result of <tt>operator*</tt> on an end iterator is undefined behavior. For any other iterator value a <tt>const
directory_entry&amp;</tt> is returned. The result of <tt>operator-&gt;</tt> on an end iterator is undefined behavior. 
For any other iterator value a <tt>const directory_entry*</tt> is returned</del><ins>The end iterator is not 
dereferenceable</ins>.
</p></blockquote>
</li>

<li><p>Add a new bullet after the class synopsis in 27.10.14 [class.rec.dir.itr]:</p>

<blockquote>
<ins>-?- Calling <code>options</code>, <code>depth</code>, <code>recursion_pending</code>, <code>pop</code> or
<code>disable_recursion_pending</code> on an iterator that is not dereferencable results in undefined behavior.</ins>

</blockquote>
</li>

<li><p>Change 27.10.14.1 [rec.dir.itr.members] as indicated:</p>

<blockquote>
<pre>
directory_options options() const;
</pre>
<blockquote>
<p>
-17- <del><i>Requires</i>: <tt>*this != recursive_directory_iterator()</tt>.</del>
<p/>
[&hellip;]
</p>
</blockquote>
<pre>
int depth() const;
</pre>
<blockquote>
<p>
-20- <del><i>Requires</i>: <tt>*this != recursive_directory_iterator()</tt>.</del>
<p/>
[&hellip;]
</p>
</blockquote>
<pre>
bool recursion_pending() const;
</pre>
<blockquote>
<p>
-23- <del><i>Requires</i>: <tt>*this != recursive_directory_iterator()</tt>.</del>
<p/>
[&hellip;]
</p>
</blockquote>
<pre>
recursive_directory_iterator&amp; operator++();
recursive_directory_iterator&amp; increment(error_code&amp; ec) noexcept;
</pre>
<blockquote>
<p>
-26- <del><i>Requires</i>: <tt>*this != recursive_directory_iterator()</tt>.</del>
<p/>
[&hellip;]
</p>
</blockquote>
<pre>
void pop();
</pre>
<blockquote>
<p>
-30- <del><i>Requires</i>: <tt>*this != recursive_directory_iterator()</tt>.</del>
<p/>
[&hellip;]
</p>
</blockquote>
<pre>
void disable_recursion_pending();
</pre>
<blockquote>
<p>
-32- <del><i>Requires</i>: <tt>*this != recursive_directory_iterator()</tt>.</del>
<p/>
[&hellip;]
</p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2711" href="#2711">2711.</a> <tt>path</tt> is convertible from approximately everything under the sun</h3>
<p><b>Section:</b> 27.10.8.4.1 [path.construct] <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Tim Song <b>Opened:</b> 2016-05-10 <b>Last modified:</b> 2016-06-24</p>
<p><b>Priority: </b>1
</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The unconstrained <tt>template&lt;class Source&gt; path(const Source&amp; source);</tt> constructor defines an 
implicit conversion from pretty much everything to <tt>path</tt>. This can lead to surprising ambiguities in 
overload resolution.
<p/>
For example, given LWG <a href="lwg-active.html#2676">2676</a>'s proposed resolution, the following code appears to be ambiguous:
</p>
<blockquote><pre>
struct meow {
  operator const char *() const;
};

std::ifstream purr(meow{});
</pre></blockquote>
<p>
because a <tt>meow</tt> can be converted to either a <tt>path</tt> or a <tt>const char*</tt> by a user-defined 
conversion, even though part of the stated goal of LWG <a href="lwg-active.html#2676">2676</a>'s P/R is to avoid "break[ing] user 
code depending on user-defined automatic conversions to the existing argument types".
</p>

<p><strong>Previous resolution [SUPERSEDED]:</strong></p>
<blockquote class="note">
<p>
This wording is relative to N4582.
</p>

<blockquote class="note">
<p>
[<i>Drafting note:</i> <tt>decay_t&lt;Source&gt;</tt> handles both the input iterator case (27.10.8.3 [path.req]/1.2) and 
the array case (27.10.8.3 [path.req]/1.3). The level of constraints required is debatable; the following wording limits 
the constraint to "is a <tt>basic_string</tt> or an iterator", but perhaps stronger constraints (e.g., an 
<tt>iterator_category</tt> check in the second case, and/or a <tt>value_type</tt> check for both cases) would be desirable.]
</p>
</blockquote>

<ol>
<li><p>Change 27.10.8.4.1 [path.construct] as indicated:</p>

<blockquote>
<pre>
template &lt;class Source&gt;
  path(const Source&amp; source);
template &lt;class InputIterator&gt;
  path(InputIterator first, InputIterator last);
</pre>
<blockquote>
<p>
-4- <i>Effects:</i> Constructs an object of class <tt>path</tt>, storing the effective range of <tt>source</tt> (27.10.8.3) 
or the range <tt>[first, last)</tt> in <tt>pathname</tt>, converting format and encoding if required (27.10.8.2.1).
<p/>
<ins>-?- <i>Remarks:</i> The first overload shall not participate in overload resolution unless either <tt>Source</tt> 
is a specialization of <tt>basic_string</tt> or the qualified-id <tt>iterator_traits&lt;decay_t&lt;Source&gt;&gt;::value_type</tt> 
is valid and denotes a type (14.8.2 [temp.deduct]).</ins>
</p>
</blockquote>
</blockquote>
</li>
</ol>
</blockquote>

<p><i>[2016-05-28, Eric Fiselier comments suggests alternative wording]</i></p>

<p>
Functions taking <tt>EcharT</tt> or <tt>Source</tt> parameter types often provide additional overloads with the 
same arity and concrete types. In order to allow conversions to these concrete types in the interface we need to 
explicitly disable the <tt>EcharT</tt> and <tt>Source</tt> overloads.
</p>

<p><i>[2016-06-19, Eric and Tim improve the wording]</i></p>


<p><i>[2016-06, Oulu]</i></p>

<p>Voted to Ready 8-0 Monday morning in Oulu</p>


<p><b>Proposed resolution:</b></p>
<p>
This wording is relative to N4594.
</p>

<blockquote class="note">
<p>
[<i>Drafting note:</i> Functions taking <tt>EcharT</tt> or <tt>Source</tt> parameter types often provide additional overloads with the 
same arity and concrete types. In order to allow conversions to these concrete types in the interface we need to explicitly disable 
the <tt>EcharT</tt> and <tt>Source</tt> overloads.]
</p>
</blockquote>

<ol>
<li><p>Change 27.10.5 [fs.req] as indicated:</p>

<blockquote>
<p>
-2- <del>Template parameters named <tt>EcharT</tt> shall be</del><ins>Functions with template parameters named 
<tt>EcharT</tt> shall not participate in overload resolution unless <tt>EcharT</tt> is</ins> one of the encoded 
character types.
</p>
</blockquote>
</li>

<li><p>Insert a new paragraph between 27.10.8.3 [path.req] p1 and p2 as indicated:</p>

<blockquote>
<p>
<ins>-?- Functions taking template parameters named <tt>Source</tt> shall not participate in overload resolution unless either 
<tt>Source</tt> is a specialization of <tt>basic_string</tt> or the qualified-id <tt>iterator_traits&lt;decay_t&lt;Source&gt;&gt;::value_type</tt> 
is valid and denotes a possibly <tt>const</tt> encoded character type (14.8.2 [temp.deduct]).</ins> 
</p>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2725" href="#2725">2725.</a> <tt>filesystem::exists(const path&amp;, error_code&amp;)</tt> error reporting</h3>
<p><b>Section:</b> 27.10.15.12 [fs.op.exists] <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2016-06-06 <b>Last modified:</b> 2016-06-24</p>
<p><b>Priority: </b>1
</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The <tt>filesystem::exists(const path&amp;)</tt> function does not throw an
exception if the file doesn't exist, but the corresponding function
taking an <tt>error_code&amp;</tt> argument does set it to indicate an error.
<p/>
It seems sensible for <tt>filesystem::exists(const path&amp;, error_code&amp;)</tt> to
call <tt>ec.clear()</tt> if <tt>status(p, ec).type() == file_type::not_found</tt>.
</p>

<p><i>[2016-06, Oulu &mdash; Jonathan comments and provides wording]</i></p>

<p>
The sentence "The signature with argument <tt>ec</tt> returns <tt>false</tt> if an error
occurs." means that given a file such that <tt>status(p).type() == file_type::unknown</tt>, 
<tt>exists(p)</tt> is <tt>true</tt> but <tt>exists(p, ec)</tt> is <tt>false</tt>.
<p/>
I believe we should make the behaviour of <tt>exists(p)</tt> and <tt>exists(p, ec)</tt>
consistent, so that the latter clears <tt>ec</tt> except when the former would
throw an exception, which is only for the <tt>file_type::none</tt> case.
</p>
<p><i>[2016-06, Oulu]</i></p>

<p>Prioritized as P1</p>
<p>Voted to Ready 7-0 Tuesday evening in Oulu</p>


<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N4594.</p>
<ol>
<li><p>Insert a new paragraph before 27.10.15.12 [fs.op.exists] p2 and edit it as shown:</p>

<blockquote>
<pre>
bool exists(const path&amp; p);
bool exists(const path&amp; p, error_code&amp; ec) noexcept;
</pre>
<blockquote>
<p>
<ins>-?- Let <tt>s</tt> be a <tt>file_status</tt>, determined as if by <tt>status(p)</tt> or <tt>status(p, ec)</tt>, 
respectively.</ins>
<p/>
<ins>-?- <i>Effects:</i> The signature with argument <tt>ec</tt> calls <tt>ec.clear()</tt> if <tt>status_known(s)</tt>.</ins>
<p/>
-2- <i>Returns:</i> <del><tt>exists(status(p))</tt> or <tt>exists(status(p, ec))</tt>, respectively</del><ins><tt>exists(s)</tt></ins>. 
<del>The signature with argument <tt>ec</tt> returns <tt>false</tt> if an error occurs</del>.
</p>
</blockquote>
</blockquote>
</li>
</ol>





</body>
</html>
