<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
    "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<meta charset="utf-8"> 
<title>Defect Report List</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}
</style>
</head>
<body>
<table>
<tr>
  <td align="left">Doc. no.</td>
  <td align="left">N4097</td>
</tr>
<tr>
  <td align="left">Date:</td>
  <td align="left">2014-07-05</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">Beman Dawes &lt;<a href="mailto:bdawes at acm dot org">bdawes at acm dot org</a>&gt;</td>
</tr>
</table>
<h1>File System TS Defect Report List (Revision R2)</h1>
<p><p>Revised 2014-07-05 at 12:07:11 UTC</p>
</p>
  <p>Reference ISO/IEC TS 18822</p>
  <p>Also see:</p>
    <ul>
      <li><a href="toc.html">Table of Contents</a> for all SG3 issues.</li>
      <li><a href="section-index.html">Index by Section</a> for all SG3 issues.</li>
      <li><a href="status-index.html">Index by Status</a> for all SG3 issues.</li>
      <li><a href="n4095.html"><replace "doc_name"/> Active Issues List</a></li>
      <li><a href="n4096.html"><replace "doc_name"/> Closed Issues List</a></li>
    </ul>
  <p>This document contains only SG3 issues which have been closed
  by the File System Study Group (SG3) after being found to be defects
  in the standard.  That is, issues which have a status of <a href="n4095.html#DR">DR</a>,
  <a href="n4095.html#TC1">TC1</a>, <a href="n4095.html#C++11">C++11</a>, 
  or <a href="n4095.html#Resolved">Resolved</a>. See the
  <a href="n4096.html"><replace "doc_name"/> Closed Issues List</a> for issues closed as non-defects.  See the
  <a href="n4095.html"><replace "doc_name"/> Active Issues List</a> for active issues and more information.  The
  introductory material in that document also applies to this
  document.</p>

<h2>Revision History</h2>
<ul>
<li>R2: 2014-07-04 SG-3 File System TS<ul>
<li><b>Summary:</b><ul>
<li>6 open issues, down by 21.</li>
<li>61 closed issues, up by 26.</li>
<li>67 issues total, up by 5.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following 5 New issues: <a href="n4095.html#64">64</a>, <a href="n4095.html#65">65</a>, <a href="n4095.html#66">66</a>, <a href="n4095.html#67">67</a>, <a href="n4095.html#68">68</a>.</li>
<li>Changed the following issue to NAD Future (from New): <a href="n4096.html#54">54</a>.</li>
<li>Changed the following issue to NAD Future (from Open): <a href="n4096.html#11">11</a>.</li>
<li>Changed the following 3 issues to WP (from Review): <a href="n4097.html#25">25</a>, <a href="n4097.html#27">27</a>, <a href="n4097.html#57">57</a>.</li>
<li>Changed the following 13 issues to WP (from New): <a href="n4097.html#34">34</a>, <a href="n4097.html#35">35</a>, <a href="n4097.html#36">36</a>, <a href="n4097.html#37">37</a>, <a href="n4097.html#40">40</a>, <a href="n4097.html#41">41</a>, <a href="n4097.html#45">45</a>, <a href="n4097.html#48">48</a>, <a href="n4097.html#49">49</a>, <a href="n4097.html#56">56</a>, <a href="n4097.html#58">58</a>, <a href="n4097.html#60">60</a>, <a href="n4097.html#62">62</a>.</li>
<li>Changed the following 3 issues to WP (from Open): <a href="n4097.html#5">5</a>, <a href="n4097.html#22">22</a>, <a href="n4097.html#53">53</a>.</li>
<li>Changed the following issue to NAD Editorial (from New): <a href="n4096.html#59">59</a>.</li>
<li>Changed the following 3 issues to NAD (from New): <a href="n4096.html#38">38</a>, <a href="n4096.html#42">42</a>, <a href="n4096.html#61">61</a>.</li>
<li>Changed the following issue to NAD (from Open): <a href="n4096.html#4">4</a>.</li>
</ul></li>
</ul>
</li>
</ul>

<h2>Defect Reports</h2>
<hr>
<h3><a name="1"></a>1. [PDTS] Make namespaces consistent with Library TS policy</h3>
<p><b>Section:</b> X All <b>Status:</b> <a href="n4095.html#WP">WP</a>
 <b>Submitter:</b> FI-5, US-5, GB-3, CH-6 <b>Opened:</b> 2014-01-20 <b>Last modified:</b> 2014-06-27</p>
<p><b>View all issues with</b> <a href="status-index.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>The PDTS used a placeholder namespace "tbs" since the Standard Library policy for
TS namespaces had not yet been fully articulated. 
</p>

  <p><i>[2014-02-11 Issaquah: Project editor to make indicated changes to WP,
  post notice on lib and SG3 reflectors.]</i></p>




<p><b>Proposed resolution:</b></p>

<p><i>[2014-02-07: Beman Dawes]</i></p>
<p>Throughout the WP, change namespace "tbs" to "experimental" as described in the
Library Fundamentals TS working paper, 1.3 Namespaces and headers [general.namespaces].
</p>

  





<hr>
<h3><a name="2"></a>2. [PDTS] Tighten specification when there is no reasonable behavior</h3>
<p><b>Section:</b> X 2.1 [fs.conform.9945] <b>Status:</b> <a href="n4095.html#WP">WP</a>
 <b>Submitter:</b> FI-1 <b>Opened:</b> 2014-01-20 <b>Last modified:</b> 2014-06-27</p>
<p><b>View all other</b> <a href="section-index.html#.1 [fs.conform.9945">issues</a> in 2.1 [fs.conform.9945].</p>
<p><b>View all issues with</b> <a href="status-index.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>It is unfortunate that error reporting for inability to provide reasonable behaviour is
completely implementation-defined. This hurts portability in the sense that programmers have no
idea how errors will be reported and cannot anticipate anything.</p>

<p>Change "If an implementation cannot provide any reasonable behavior, the implementation
shall report an error in an implementation-defined manner." to "If an implementation cannot
provide any reasonable behavior, the code using the facilities for which reasonable behaviour
cannot be provided shall be ill-formed." and strike the note.</p>

  <p><i>[2014-02-07, Beman Dawes suggests wording]</i></p>


  <p><i>[2014-02-12, Daniel Krgler comments:]</i></p>


  <blockquote>
  <p/>In our code bases we routinely have to target different filesystems,
  notably POSIX-based and Windows. While on Windows there is no meaning
  in setting the <tt>owner_exec</tt> permission, for example, this is required on
  POSIX systems when the corresponding file should be executable. Still,
  attempting to invoke this operation should be possible. It would be
  OK, if we got a defined runtime response to this, such as a
  specifically defined error code value that could be tested either via
  the error_code&amp; overload, but it would be IMO unacceptable for
  end-users to tell them "Well, this code may not compile". I don't
  think that we can teach people that code written using the filesystem
  operations might or might not compile. It would be very valuable to
  have at least a clear indication that implementers are required to
  give a defined runtime-response if they do believe that this operation
  cannot be implemented resulting in "reasonable behaviour".
  </blockquote>

  <p><i>[2014-02-12, Proposed wording updated to reflect LWG/SG-3 discussion in Issaquah.
  <p/>Since the standardese to carry out the LWG/SG-3 "throw or error code" intent is
  best achieved by reference to the Error reporting section, a note was added by the project
  editor. Please review carefully.
  ]</i></p>


  <p><i>[2014-02-13 LWG/SG-3 Issaquah: Proposed wording accepted.]</i></p>





<p><b>Proposed resolution:</b></p>

<ol>
<li><p>Change 2.1:</p>
<blockquote><p>
If an implementation cannot provide any reasonable behavior,
the implementation shall report an error <del>in an implementation-defined manner</del>
<ins>as specified in &sect; 7 [fs.err.report]. [<i>Note:</i> This allows users
to rely on an exception being thrown or an error code being set when an
implementation cannot provide any reasonable behavior. &mdash; <i>end note</i>]
</ins>.
</p></blockquote>
</li>
</ol>






<hr>
<h3><a name="3"></a>3. [PDTS] Filename length needs bullet item</h3>
<p><b>Section:</b> X 4.7 [fs.def.filename] <b>Status:</b> <a href="n4095.html#WP">WP</a>
 <b>Submitter:</b> CH-2 <b>Opened:</b> 2014-01-20 <b>Last modified:</b> 2014-06-27</p>
<p><b>View all issues with</b> <a href="status-index.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>Filename lengths are also implementation dependent. This is not the same as
<tt>FILENAME_MAX</tt> that specifies the maximum length of pathnames.</p>

<p>Add a bullet: "Length of filenames."</p>

<p><i>[2014-02-07, Beman Dawes provides wording]</i></p>



<p><b>Proposed resolution:</b></p>
<p>Change 4.7 [fs.def.filename]:</p>
  <p>The name of a file. Filenames dot&nbsp; and dot-dot&nbsp; have special meaning. The following characteristics of 
  filenames are operating system dependent:</p>
<ul>
  <li>
  <p>The permitted characters. [<i>Example</i>: Some operating systems prohibit the ASCII control characters (0x00-0x1F) 
    in filenames. &mdash; <i>end example</i>].</p>
  </li>
  <li><ins>The maximum permitted length.</ins></li>
  <li>
  <p>Filenames that are not permitted.</p>
  </li>
  <li>
  <p>Filenames that have special meaning.</p>
  </li>
  <li>
  <p>Case awareness and sensitivity during path resolution.</p>
  </li>
  <li>
  <p>Special rules that may apply to file types other than regular 
  files, such as directories.</p>
  </li>
</ul>





<hr>
<h3><a name="5"></a>5. [PDTS] Parent of root directory unspecified</h3>
<p><b>Section:</b> X 8.1 [path.generic] <b>Status:</b> <a href="n4095.html#WP">WP</a>
 <b>Submitter:</b> CH-4 <b>Opened:</b> 2014-01-20 <b>Last modified:</b> 2014-07-04</p>
<p><b>View all issues with</b> <a href="status-index.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>8.1 [path.generic] says:
"The filename dot-dot is treated as a reference to the parent directory." So it must be
specified what "/.." and "/../.." refer to.</p>

<p>Add a statement what the parent directory of the root directory is.</p>

  <p><i>[2014-02-07, Beman Dawes suggests wording]</i></p>

  
  <p><i>[
    2014-02-11 Issaquah: Implementation defined. See wiki notes for rationale.
    Beman to provide wording for review next meeting.
  ]</i></p>


  <p><i>[
    22 May 2014 Beman provides wording, taken directly from POSIX.
    See pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xbd_chap04.html#tag_21_04_12
  ]</i></p>




<p><b>Proposed resolution:</b></p>

<ol>
<li>
<p>Change 8.1 [path.generic]:</p>

<blockquote><p>
The filename <i>dot</i> is treated as a reference to the current directory.
The filename <i>dot-dot</i> is treated as a reference to the parent directory.
<ins>What the filename <i>dot-dot</i> refers to relative to <i>root-directory</i> is implementation-defined.</ins>
Specific filenames may have special meanings for a particular operating system.
</p></blockquote>
</li>
</ol>






<hr>
<h3><a name="6"></a>6. [PDTS] Path depth is underspecified</h3>
<p><b>Section:</b> X 4.15 [fs.def.path] <b>Status:</b> <a href="n4095.html#WP">WP</a>
 <b>Submitter:</b> CH-5 <b>Opened:</b> 2014-01-20 <b>Last modified:</b> 2014-05-24</p>
<p><b>View all issues with</b> <a href="status-index.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>Path depth is implementation dependent.</p>

<p>Add a paragraph: "The maximum length of the sequence (i.e. the maximum depth) is
 implementation dependent.</p>

 <p><i>[2014-02-07, Beman Dawes comments]</i></p>


   <p>
    "implementaton defined" and "operating system dependent"
    are well defined terms in this TS, but "implementation dependent" is not well defined.
    The path depth is operating system dependent, so that's the form used in the proposed wording.
  </p>

 <p><i>[2014-02-07, Beman Dawes provides wording]</i></p>




<p><b>Proposed resolution:</b></p>
  <p><i>Change 4.15 [fs.def.path]:</i></p>
  <blockquote>
  <p>
    <b>4.15  path [fs.def.path]</b>
  </p>
    <p>
      A sequence of elements that identify
      the location of a file within a filesystem. The elements are the <i>
        root-name<sub>opt</sub>
      </i>, <i>
        root-directory<sub>opt</sub>
      </i>,
      and an optional sequence of filenames.
    </p>
  <p>
    <ins>
      The maximum number of elements in the sequence is
      operating system dependent.
    </ins>
  </p>
  </blockquote>





<hr>
<h3><a name="7"></a>7. [PDTS] Unhelpful comment for <tt>struct space_info</tt></h3>
<p><b>Section:</b> X 6 [fs.filesystem.synopsis], 15.32 [fs.op.space] <b>Status:</b> <a href="n4095.html#WP">WP</a>
 <b>Submitter:</b> GB-4 <b>Opened:</b> 2014-01-20 <b>Last modified:</b> 2014-05-24</p>
<p><b>View all issues with</b> <a href="status-index.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>Use of the term a 'non-privileged' process.
The comment for available in the struct space_info refers to: free space available to a
non-privileged process.
This seems quite specific to a POSIX implementation (on Windows, for instance, the
equivalent data would be user-specific but not directly related to privilege)</p>

<p>Remove the comment and add a note to 15.32 [fs.op.space]:
[<i>Note</i>: the precise meaning of available space is implementation dependent. &mdash; <i>end note</i>]</p>

<p><i>[2014-02-07, Beman Dawes comments]</i></p>


<p>
"implementaton defined" and "operating system dependent"
    are well defined terms in this TS, but "implementation dependent" is not well defined.
    The meaning of <code>available</code> is operating system dependent, so that's the form used 
    in the proposed wording.
</p>

<p><i>[2014-02-07, Beman Dawes provides wording]</i></p>




<p><b>Proposed resolution:</b></p>

<ol>
<li>
  <p>
  <i>Change 6 [fs.filesystem.synopsis]:</i>
  </p>
  
  <blockquote>
     <p>
      <code>uintmax_t available; <del>// free space available to a non-privileged process</del></code>
    </p>
  </blockquote>
</li>

<li>
  <p>
    <p><i>Add Remarks to 15.32 [fs.op.space]:</i></p>
  </p>
  <blockquote>
    <p>
      <ins>
        <i>Remarks:</i> The value of member <code>space_info::available</code>
        is operating system dependent. [<i>Note:</i> <code>available</code> may be less than
        <code>free</code>. <i>&mdash; end note</i>]
      </ins>
    </p>
  </blockquote>
</li>
</ol>






<hr>
<h3><a name="8"></a>8. [PDTS] <tt>file_time_type</tt> underspecified</h3>
<p><b>Section:</b> X [fs.filesystem.synopsis] <b>Status:</b> <a href="n4095.html#WP">WP</a>
 <b>Submitter:</b> CH-7 <b>Opened:</b> 2014-01-20 <b>Last modified:</b> 2014-06-27</p>
<p><b>View all issues with</b> <a href="status-index.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>Must the <tt>file_time_type</tt> hold times before 1960 and after 2050?</p>

<p>Specify the requirements to <i>unspecified-trivial-clock</i> for <tt>file_time_type</tt>.</p>

<p><i>[2014-02-10, Daniel suggests wording]</i></p>

  <p><i>[
    2014-02-11 Issaquah: (1)Implementation-defined. See wiki notes for rationale.
    (2) Leave other additions in place, but insert "the" before "resolution"
    (3) Strike "unspecified-" from "unspecified-trivial-type" in two places.
    Beman to provide wording for review next meeting.
  ]</i></p>


  <p><i>[2014-02-13 LWG/SG-3 Issaquah: Proposed wording accepted.]</i></p>




<p><b>Proposed resolution:</b></p>
<ol>
<li><p>Modify 6 [fs.filesystem.synopsis] as indicated:</p>

<blockquote>
  <pre>
    typedef chrono::time_point&lt;<b><i><del>unspecified-</del>trivial-clock</i></b>&gt;  file_time_type;
  </pre> 
<p>
<em><del>unspecified-</del>trivial-clock</em> is an <del>unspecified type provided by the implementation</del>
<ins>implementation-defined type</ins> that satisfies the TrivialClock requirements 
(<del>C++11</del><ins>ISO 14882:2011</ins> &sect;20.12.3) and that is capable of representing and measuring file time values. 
<ins>Implementations should ensure that the resolution and range of <tt>file_time_type</tt> reflect the operating system dependent 
resolution and range of file time values.</ins>
</p></blockquote>
</li>
</ol>





<hr>
<h3><a name="9"></a>9. [PDTS] Unclear why range-based-for functions return different types</h3>
<p><b>Section:</b> X 6 [fs.filesystem.synopsis] <b>Status:</b> <a href="n4095.html#WP">WP</a>
 <b>Submitter:</b> FI-2 <b>Opened:</b> 2014-01-20 <b>Last modified:</b> 2014-05-24</p>
<p><b>View all other</b> <a href="section-index.html# [fs.filesystem.synopsis">issues</a> in 6 [fs.filesystem.synopsis].</p>
<p><b>View all issues with</b> <a href="status-index.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>It is unclear why the range-for support functions (begin()/end()) for
<tt>directory_iterator</tt> and <tt>recursive_directory_iterator</tt> return different types for <tt>begin()</tt>
and <tt>end()</tt>, namely that <tt>begin()</tt> returns a reference to <tt>const</tt> and <tt>end()</tt> returns a value.</p>

  <p>
    <i>[2014-02-07: Beman Dawes provides comments from the Boost implementation:]</i>
  </p>


  <pre>
  //  begin() and end() are only used by a range-based for statement in the context of
  //  auto - thus the top-level const is stripped - so returning const is harmless and
  //  emphasizes begin() is just a pass through.</pre>

  <p><i>[2014-02-08: Daniel responds to Beman]</i></p>

  
  <p>
  The difference in return types becomes relevant, when testing whether e.g. <tt>directory_iterator</tt>
  would satisfy the <tt>Traversable</tt> requirements as currently specified in 
  <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3763.html">N3763</a>. Expressed in
  code form these requirements impose that the following assertion holds:
  </p>
  <blockquote><pre>
  static_assert(std::is_same&lt;
      decltype(std::range_begin(std::declval&lt;directory_iterator&gt;())),
      decltype(std::range_end(std::declval&lt;directory_iterator&gt;()))
    &gt;::value, "No Traversable type");
  </pre></blockquote>
  <p>
  Both <tt>directory_iterator</tt> and <tt>recursive_directory_iterator</tt> won't satisfy this requirement
  currently.
  </p>
  <p><i>[
    2014-02-11 Issaquah: Change begin() argument and return to pass-by-value. See wiki notes for rationale.
    Beman to provide wording for review next meeting.
  ]</i></p>


  <p><i>[2014-02-13 LWG/SG-3 Issaquah: Proposed wording accepted.]</i></p>




<p><b>Proposed resolution:</b></p>
<ol>
<li>
  <p><i>Change 6 [fs.filesystem.synopsis]:</i></p>
  
  <pre>
  class directory_iterator;

  // enable directory_iterator range-based for statements
  <del>const</del> directory_iterator<del>&amp;</del> begin(<del>const</del> directory_iterator<del>&amp;</del> iter) noexcept;
  directory_iterator end(const directory_iterator&amp;) noexcept;

  class recursive_directory_iterator;

  // enable recursive_directory_iterator range-based for statements
  <del>const</del> recursive_directory_iterator<del>&amp;</del> begin(<del>const</del> recursive_directory_iterator<del>&amp;</del> iter) noexcept;
  recursive_directory_iterator end(const recursive_directory_iterator&amp;) noexcept;
  </pre>
</li>
<li>
  <p><i>
    Change 13.2 [directory_iterator.nonmembers]:
  </i></p>
  <p>
    These functions enable use of <code>directory_iterator</code> with C++11
    range-based for statements.
  </p>
  <pre><del>const</del> directory_iterator<del>&amp;</del> begin(<del>const</del>directory_iterator<del>&amp;</del> iter) noexcept;</pre>
  <blockquote>
    <p>
      <i>Returns: </i><code>iter</code>.
    </p>
  </blockquote>
  <pre>directory_iterator end(const directory_iterator&amp;) noexcept;</pre>
  <blockquote>
    <p>
      <i>Returns: </i><code>directory_iterator()</code>.
    </p>
  </blockquote>
</li>
<li>
  <p><i>
    Change 14.2 [rec.dir.itr.nonmembers]:
  </i></p>
  <p>
    These functions enable use of <code>recursive_directory_iterator</code>
    with C++11 range-based for statements.
  </p>
  <pre><del>const</del> recursive_directory_iterator<del>&amp;</del> begin(<del>const</del>recursive_directory_iterator<del>&amp;</del> iter) noexcept;</pre>
  <blockquote>
    <p>
      <i>Returns: </i><code>iter</code>.
    </p>
  </blockquote>
  <pre>recursive_directory_iterator end(const recursive_directory_iterator&amp;) noexcept;</pre>
  <blockquote>
    <p>
      <i>Returns: </i><code>recursive_directory_iterator()</code>.
    </p>
  </blockquote>
</li>
</ol>







<hr>
<h3><a name="14"></a>14. [PDTS] Incorrect postconditions for <tt>path</tt> copy/move constructor</h3>
<p><b>Section:</b> X 8.4.1 [path.construct] <b>Status:</b> <a href="n4095.html#WP">WP</a>
 <b>Submitter:</b> GB-7, CH-10 <b>Opened:</b> 2014-01-20 <b>Last modified:</b> 2014-05-24</p>
<p><b>View all other</b> <a href="section-index.html#.4.1 [path.construct">issues</a> in 8.4.1 [path.construct].</p>
<p><b>View all issues with</b> <a href="status-index.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>The postconditions for the copy/move constructor for path are shown as "empty()".
This appears to have been incorrectly copied from the default ctor.</p>

<p>Remove the 'postconditions' clause from the copy/move ctor.</p>

<p><i>[2014-02-07, Beman Dawes suggests wording]</i></p>




<p><b>Proposed resolution:</b></p>
    <p>
      <i>Change 8.4.1 [path.construct]:</i>
    </p>
    <blockquote>
    <pre>
      path(const path&amp; p);
      path(path&amp;&amp; p) noexcept;
    </pre>
    <blockquote>
      <p>
        <i>Effects:</i> Constructs an object of class <code>path</code> with <code>
          pathname
        </code> having the original value of <code>p.pathname</code>. In the
        second form, <code>p</code> is left in a valid but unspecified state.
      </p>
      <p>
        <del><i>Postconditions:</i> empty().</del>
      </p>
    </blockquote>
    </blockquote>





<hr>
<h3><a name="15"></a>15. [PDTS] Missing behavior for characters with no representation</h3>
<p><b>Section:</b> X 8.2.2 [path.type.cvt], X 8.4.1 [path.construct] <b>Status:</b> <a href="n4095.html#WP">WP</a>
 <b>Submitter:</b> GB-8 <b>Opened:</b> 2014-01-20 <b>Last modified:</b> 2014-06-27</p>
<p><b>View all issues with</b> <a href="status-index.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
  No specification for characters with no representation. The example at the end of
  8.4.1 refers to "for other native narrow encodings some characters may have no
  representation" - what happens in such cases?</p>

  <p>Suggested action:</p>
  <p>Add some definition of the behaviour for characters with no representation.</p>

  <p><i>[2014-02-12 Applied LWG/SG-3 Issaquah wording tweaks to make characters referred to plural.]</i></p>


  <p><i>[2014-02-08, Beman Dawes provides wording]</i></p>



<p><b>Proposed resolution:</b></p>
  <p>
    <i>Add a paragraph at the end of 8.2.2 [path.type.cvt]:</i>
  </p>
  <blockquote><p>
    <ins>If the encoding being converted to has no representation for source characters,
    the resulting converted characters, if any, are unspecified.</ins>
  </p></blockquote>






<hr>
<h3><a name="16"></a>16. [PDTS] Append behavior underspecified if target is empty </h3>
<p><b>Section:</b> X 8.4.3 [path.append] <b>Status:</b> <a href="n4095.html#WP">WP</a>
 <b>Submitter:</b> CH-11 <b>Opened:</b> 2014-01-20 <b>Last modified:</b> 2014-06-27</p>
<p><b>View all issues with</b> <a href="status-index.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>Is the added separator redundant in p1 /= p2, where p1 is empty? 
I.e. does the result start with a separator?</p>

<p>Suggested action:</p>
<p>Specify what behaviour is required.</p>
  
  <p><i>[2014-02-07: Beman Dawes comments]</i></p>
 
  <p>The second bullet item is supposed to deal with the <tt>empty()</tt> condition.</p>

  <p><i>[2014-02-12 LWG/SG-3 Issaquah: The text is correct as written, however
  adding a note will clarify this and address the NB comment.]</i></p>
  
  


<p><b>Proposed resolution:</b></p>
  <p>
    <i>Change 8.4.3 [path.append]:</i>
  </p>
  <blockquote>
  <p>
    <i>Effects:</i>
  </p>
  <blockquote><p>
    Appends <code>path::preferred_separator</code> to <code>pathname</code> unless:
   </p>
    <ul>
      <li><p>
        an added separator
        would be redundant, or
      </p></li>
      <li><p>would change a<del>n</del> relative path to a<del>n</del> absolute path
      <ins>[<i>Note</i>: An empty path is relative. &mdash; <i>end note</i>]</ins>, or</p></li>
      <li><p>
        <code>p.empty()</code>, or
      </p></li>
      <li><p>
        <code>*p.native().cbegin()</code> is a directory separator.
      </p></li>
    </ul>
    <p>
      Then appends <code>p.native()</code> to <code>pathname</code>.
    </p>
    </blockquote>
    </blockquote>
  




<hr>
<h3><a name="18"></a>18. [PDTS] <tt>is_absolute()</tt> return clause confusing</h3>
<p><b>Section:</b> X 8.4.10 [path.query] <b>Status:</b> <a href="n4095.html#WP">WP</a>
 <b>Submitter:</b> FI-7 <b>Opened:</b> 2014-01-20 <b>Last modified:</b> 2014-05-24</p>
<p><b>View all issues with</b> <a href="status-index.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p><tt>is_absolute</tt> says: "Returns: true if the elements of <tt>root_path()</tt> uniquely identify
a file system location, else false." The "uniquely identify a location" seems confusing
in presence of symlinks.
</p>
<p>Suggested action:</p>
<p>Clarify the returns clause so that there's no confusion about symlinks and 'location'.</p>

  <p><i>[2014-02-10 Beman Dawes provides wording]</i></p>





<p><b>Proposed resolution:</b></p>
  <p>
  <i>Change 8.4.10 path query [path.query]:</i>
  </p>
  <blockquote>
    <pre>bool <a name="path-is_absolute">is_absolute</a>() const;</pre>
    <blockquote>
      <p>
        <i>Returns:</i> <code>true</code> if <del>
          the elements of <code>root_path()</code> uniquely identify a
          file system location
        </del> <ins>
          <code>pathname</code> contains an absolute path (4.1 [fs.def.absolute-path])
        </ins>, else <code>false</code>.
      </p>
    </blockquote>
    <blockquote>
      [<i>Example:</i> <code>path(&quot;/&quot;).is_absolute()</code> is
      <code>true</code> for POSIX based operating systems, and <code>false</code> for Windows based
      operating systems.&nbsp; &mdash; <i>end example</i>]
    </blockquote>
  </blockquote>






<hr>
<h3><a name="19"></a>19. [PDTS] Consider using quoted manipulators</h3>
<p><b>Section:</b> X 8.6.1 [path.io] <b>Status:</b> <a href="n4095.html#WP">WP</a>
 <b>Submitter:</b> FI-8 <b>Opened:</b> 2014-01-20 <b>Last modified:</b> 2014-06-27</p>
<p><b>View all issues with</b> <a href="status-index.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>"[<i>Note</i>: Pathnames containing spaces require special handling by the user to avoid
truncation when read by the extractor. &mdash; <i>end note</i>]" sounds like a quoted manipulator
as specified in the C++14 draft in [quoted.manip] would be useful.</p>

<p>Consider using quoted manipulators for stream insertion and extraction.</p>

<p><i>[2014-02-10, Daniel suggests wording]</i></p>


<p><i>[2014-02-12 Applied LWG/SG-3 Issaquah wording tweak to use ISO doc number for reference to C++14.]</i></p>




<p><b>Proposed resolution:</b></p>

<ol>
<li><p>Change 8.6.1 [path.io] as indicated:</p>

<blockquote><pre>
template &lt;class charT, class traits&gt;
basic_ostream&lt;charT, traits&gt;&amp;
operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp; os, const path&amp; p);
</pre>
<blockquote>
<p>
<i>Effects</i>: <tt>os &lt;&lt; <ins>quoted(</ins>p.string&lt;charT, traits&gt;()<ins>)</ins></tt>.
<p/>
<del>
  [<i>Note</i>: Pathnames containing spaces require special handling by the user to avoid truncation when read by the extractor.
  &mdash; <i>end note</i>]
</del>
  <p/>
  <ins>
    [<i>Note</i>: The <code>quoted</code> function is described in ISO 14882:2014 27.7.6.
    &mdash; <i>end note</i>]
  </ins>
  <p/>
<i>Returns</i>: <tt>os</tt>
</p>
</blockquote>
<pre>
template &lt;class charT, class traits&gt;
basic_istream&lt;charT, traits&gt;&amp;
operator&gt;&gt;(basic_istream&lt;charT, traits&gt;&amp; is, path&amp; p);
</pre>
<blockquote>
<p>
<i>Effects</i>:
</p>
<blockquote><pre>
basic_string&lt;charT, traits&gt; tmp;
is &gt;&gt; <ins>quoted(</ins>tmp<ins>)</ins>;
p = tmp;
</pre></blockquote>
<p>
</p>
</blockquote>
</blockquote>

</li>
</ol>






<hr>
<h3><a name="21"></a>21. [PDTS] <tt>directory_entry operator==</tt> needs clarification</h3>
<p><b>Section:</b> X 12.3 [directory_entry.obs] <b>Status:</b> <a href="n4095.html#WP">WP</a>
 <b>Submitter:</b> GB-12 <b>Opened:</b> 2014-01-20 <b>Last modified:</b> 2014-06-27</p>
<p><b>View all other</b> <a href="section-index.html#2.3 [directory_entry.obs">issues</a> in 12.3 [directory_entry.obs].</p>
<p><b>View all issues with</b> <a href="status-index.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>Since <tt>operator==</tt> for <tt>directory_entry</tt> does not check status, it would be worth
highlighting that <tt>operator==</tt> only checks that the paths match.</p>
<p>Suggested action:</p>
<p>Add: [<i>Note</i>: does not include status values &mdash; <i>end note</i>]</p>

  <p><i>[2014-02-09, Beman Dawes suggest wording]</i></p>


  <p><i>[2014-02-13 LWG/SG-3 Issaquah: Proposed wording accepted. Typo /no/not/ fixed per suggestion.]</i></p>




<p><b>Proposed resolution:</b></p>
  <p/>
  <i>To 12.3 [directory_entry.obs] <tt>operator==</tt> add:</i>

  <p/><ins>
    [<i>Note:</i> Status members do not participate in determining equality. &mdash; <ins>end note</ins>]</ins>

  <blockquote>
  </blockquote>






<hr>
<h3><a name="22"></a>22. [PDTS] <tt>directory_iterator</tt> underspecified</h3>
<p><b>Section:</b> X 13.1 [directory_iterator.members] <b>Status:</b> <a href="n4095.html#WP">WP</a>
 <b>Submitter:</b> CH-13 <b>Opened:</b> 2014-01-20 <b>Last modified:</b> 2014-07-04</p>
<p><b>View all issues with</b> <a href="status-index.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>The behaviour of increment is underspecified: What happens if the implementation
detects an endless loop (e.g. caused by links)? What happens with automounting and
possible race conditions?</p>
<p>More information on this can be found <a href="http://man7.org/linux/manpages/man3/fts.3.html">here</a>.
<p>Suggested action:</p>
<p>Specify the required behaviour in these cases.</p>
</p>
  <p><i>[2014-02-13 LWG/SG-3 Issaquah: STL will provide wording for next meeting for
  the endless loop case. The other cases are covered by existing wording in the front matter.]</i></p>


  <p><i>[17 Jun 2014 At the request of the LWG, Beman provides wording for a note.]</i></p>
  



<p><b>Proposed resolution:</b></p>
  <p>
    <i>In 14 Class recursive_directory_iterator [class.rec.dir.itr], add:</i>
  </p>
  <blockquote>
    <p>
      <ins>
        [<i>Note: </i>If the directory structure being iterated over contains
        cycles then
        the end iterator may be unreachable. <i>--end note</i>]
      </ins>
    </p>
  </blockquote>






<hr>
<h3><a name="24"></a>24. [PDTS] Incorrect effects clause for path <tt>copy</tt></h3>
<p><b>Section:</b> X 15.3 [fs.op.copy] <b>Status:</b> <a href="n4095.html#WP">WP</a>
 <b>Submitter:</b> GB-14 <b>Opened:</b> 2014-01-20 <b>Last modified:</b> 2014-06-27</p>
<p><b>View all issues with</b> <a href="status-index.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>Incorrect effects clause for path copy &mdash; the effect clause for <tt>copy</tt> [fs.op.copy]
includes "<tt>equivalent(f, t)</tt>" &mdash; there is no <tt>equivalent()</tt> function defined for variables
of this type (<tt>file_status</tt>)</p>
<p>Suggested action:</p>
<p>Replace with "<tt>equivalent(from, to)</tt>"</p>

  <p><i>[2014-02-09, Beman Dawes suggests wording]</i></p>


  <p><i>[2014-02-13 LWG/SG-3 Issaquah: Proposed wording accepted.]</i></p>




<p><b>Proposed resolution:</b></p>
  <p/>  <i>Change 15.3 [fs.op.copy]:</i>

  <blockquote>
    <p>
      Report an error as specified in <a href="#Error-reporting">Error reporting</a>
      if:
    </p>

    <ul>
      <li>
        <code>!exists(f)</code>.
      </li>
      <li>
        <code>equivalent(<del>f, t</del> <ins>from, to</ins>)</code>.
      </li>
      <li>
        <code>is_other(f) || is_other(t)</code>.
      </li>
      <li>
        <code>is_directory(f) &amp;&amp; is_regular_file(t)</code>.
      </li>
    </ul>
  </blockquote>






<hr>
<h3><a name="25"></a>25. [PDTS] Copying equivalent paths effects not specified</h3>
<p><b>Section:</b> X 15.4 [fs.op.copy_file] <b>Status:</b> <a href="n4095.html#WP">WP</a>
 <b>Submitter:</b> CH-15 <b>Opened:</b> 2014-01-20 <b>Last modified:</b> 2014-07-04</p>
<p><b>View all issues with</b> <a href="status-index.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>Even if <tt>to</tt> and <tt>from</tt> are different paths, they may be equivalent.</p>

<p>Specify what happens if <tt>(options &amp; copy_options::overwrite_existing)</tt> but <tt>from</tt> and <tt>to</tt>
resolve to the same file.</p>

  <p><i>[2014-02-09, Beman Dawes: Need advice on this issue:]</i></p>


  <p/>What do existing implentations do?

  <p/>Possible resolutions:
  <ol>
    <li>Treat it as an error.</li>
    <li>Once equivalence is determined, take no further action and return true? false?</li>
    <li>Don't bother to detect a file overwriting itself. This will likely result in an error, anyhow.</li>
  </ol>
  <p><i>[2014-02-13 LWG/SG-3 Issaquah: LWG/SG-3 decided to treat equivalence in this case as an error.
  Beman to provide wording.]</i></p>


  <p><i>[2014-04-09 Beman provided wording as requested. The Effects were rewritten to increase
  clarity. Behavior remains unchanged except for treating equivalence as an error.]</i></p>


  <p><i>[17 Jun 2014 Rapperswil LWG moves to Immediate. Jonathan Wakely will provide editorial
  changes to improve the presentation of bitmask values.]</i></p>




<p><b>Proposed resolution:</b></p>
  <p/>
  <i>Change 15.4 [fs.op.copy_file]:</i>

  <blockquote>
    <p>
      <i>Precondition:</i> At most one constant from each <code>copy_options</code>
      option group ([<a href="#enum.copy_options">enum.copy_options</a>]) is present
      in <code>options</code>.
    </p>

    <p>
      <i>Effects:</i>
    </p>
    <blockquote>
      
        <p><del>
          If&nbsp; <code>exists(to) &amp;&amp;</code> <code>
            !(options &amp; (copy_options::skip_existing
            | copy_options::overwrite_existing | copy_options::update_existing))
          </code> report a
          file already exists error as specified in <a href="#Error-reporting">Error reporting (7)</a>.
        </del></p>
      
      
        <p><del>
          If <code>
            !exists(to) || (options &amp; copy_options::overwrite_existing) || ((options &amp; copy_options::update_existing)
            &amp;&amp; last_write_time(from) &gt; last_write_time(to)) || !(options &amp; (copy_options::skip_existing
            | copy_options::overwrite_existing | copy_options::update_existing))
          </code> copy the contents and attributes of the file <code>from</code>
          resolves to  the file <code>to</code> resolves to.
        </del></p>
      
    </blockquote>
    <blockquote>
      
        <p>
          <ins>
            Report a file already exists error as specified in
            <a href="file:///C:/dot16/filesystem-ts/working-draft.html#Error-reporting">
              Error reporting (7)
            </a> if:
          </ins>
        </p>
        <ul>
          <li><ins>
              <ins><code>exists(to)</code> and <code>equivalent(from, to)</code>,
              or</ins>
          </ins></li>
          <li><ins>
              <code>exists(to)</code> and <code>
                (options &amp; (copy_options::skip_existing
                | copy_options::overwrite_existing | copy_options::update_existing)) == copy_options::none.
              </code>
          </ins></li>
        </ul>
        <p><ins>
          Otherwise copy the contents and attributes of the file <code>from</code>
          resolves to to the file <code>to</code> resolves to if:
          </ins></p>
        <ul>
          <li><ins>
              <code>!exists(to)</code>, or
          </ins></li>
          <li><ins>
            <code>exists(to)</code> and <code>
              (options &amp;
              copy_options::overwrite_existing) != copy_options::none
            </code>, or
          </ins></li>
          <li><ins>
            <code>exists(to)</code> and <code>
              (options &amp;
              copy_options::update_existing) != copy_options::none
            </code> and <code>from</code> is more
            recent than <code>to</code>, determined as if by use of the <code>
              last_write_time
            </code> function.
          </ins></li>
        </ul>
        <p><ins>Otherwise no effects.</ins></p>
      
    </blockquote>

    <p>
      <i>Returns</i>: <code>true</code> if the <code>from</code> file
      was copied, otherwise <code>false</code>. The signature with argument <code>ec</code> return
      <code>false</code> if an error occurs.
    </p>
    <p>
      <i>Throws:</i> As specified in <a href="#Error-reporting">Error reporting (7)</a>.
    </p>
    <p>
      <i>Complexity:</i> At most one direct or indirect invocation of <code>
        status(to)</code>.
    </p>
  </blockquote>
  





<hr>
<h3><a name="27"></a>27. [PDTS] Return value of <tt>uintmax_t</tt> on error?</h3>
<p><b>Section:</b> X 15.14 [fs.op.file_size] <b>Status:</b> <a href="n4095.html#WP">WP</a>
 <b>Submitter:</b> FI-9 <b>Opened:</b> 2014-01-20 <b>Last modified:</b> 2014-07-04</p>
<p><b>View all issues with</b> <a href="status-index.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>"The signature with argument <tt>ec</tt> returns <tt>static_cast&lt;uintmax_t&gt;(-1)</tt> if an error
occurs.", one would expect that <b>both</b> signatures return that if an error occurs?</p>

<p>Clarify the Returns clause, and apply the same for every function that returns an
<tt>uintmax_t</tt> where applicable.</p>
  
 <p><i>[2014-02-13 LWG/SG-3 Issaquah:]</i></p>


  <p/>Discussion when around in circles for a while, until someone suggested the reference to 15.15 was wrong,
  and that the issue applied to the previous function in the WP, 15.14 File size [fs.op.file_size].
  
  <p/>The NB Comment makes much more sense if it applies to file_size(), so the chair was directed
  to change the reference from 15.15 [fs.op.hard_lk_ct] to 15.14 [fs.op.file_size].
  
  <p/>The intent that file_size() is only meaningful for regular_files. Beman to strike the
  the static_cast, changing it to "Otherwise an error is reported.".  
  



<p><b>Proposed resolution:</b></p>
  <p>
    <i>Change 15.14 [fs.op.file_size]:</i>
  </p>

<pre>uintmax_t file_size(const path&amp; p);
uintmax_t file_size(const path&amp; p, error_code&amp; ec) noexcept;</pre>
<blockquote>
  <p><i>Returns:</i> If <code>
    <ins>!</ins>exists(p) <del>&amp;&amp;</del>  <ins>|| !</ins>is_regular_file(p)</code><ins>
      an error is reported (7). Otherwise</ins>, the size in bytes 
  of the file <code>p</code> resolves to, determined as if by the value of the 
  POSIX <code>stat</code> structure member <code>st_size</code> 
  obtained as if by POSIX <code>stat()</code>. 
  <del>Otherwise, <code>static_cast&lt;uintmax_t&gt;(-1)</code>.</del> The signature with 
  argument <code>ec</code> 
  returns <code>static_cast&lt;uintmax_t&gt;(-1)</code> if an error occurs.</p>
  <p><i>Throws:</i> As specified in <a href="#Error-reporting">Error reporting <ins>(7)</ins></a>.</p>
</blockquote>







<hr>
<h3><a name="29"></a>29. [PDTS] Unclear semantics of <tt>read_symlink</tt> on error</h3>
<p><b>Section:</b> X 15.27 [fs.op.read_symlink] <b>Status:</b> <a href="n4095.html#WP">WP</a>
 <b>Submitter:</b> GB-16 <b>Opened:</b> 2014-01-20 <b>Last modified:</b> 2014-06-27</p>
<p><b>View all issues with</b> <a href="status-index.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>Unclear semantics of read_symlink on error: 15.27 [fs.op.read_symlink] has:
Returns: If p resolves to a symbolic link, a path object containing the contents of
that symbolic link. Otherwise path(). and also [Note: It is an error if p does not
resolve to a symbolic link. -- end note]</p>
<p>I do not believe path() can be a valid return for the overload not taking error_code.</p>

<p>Strike "Otherwise <tt>path()</tt>."</p>

  <p><i>[2014-02-09, Beman Dawes provides wording]</i></p>


  <p/>

  <p><i>[2014-02-13 LWG/SG-3 Issaquah: Proposed wording accepted.]</i></p>




<p><b>Proposed resolution:</b></p>
  <i>Change 15.27 [fs.op.read_symlink]:</i>

  <blockquote>
    <p>
      <i>Returns:</i>&nbsp; If <code>p</code> resolves to a symbolic
      link, a <code>path</code> object containing the contents of that symbolic
      link. <del>Otherwise <code>path()</code>.</del> The signature with argument <code>ec</code>
      returns <code>path()</code> if an error occurs.
    </p>
    <p>
      <i>Throws:</i> As specified in <a href="#Error-reporting">Error reporting</a>. [<i>Note:</i> It is an error if 
      <code>p</code> does not resolve to a symbolic link. &mdash; <i>end note</i>]
    </p>
  </blockquote>







<hr>
<h3><a name="32"></a>32. [PDTS] <tt>system_complete()</tt> example needs clarification</h3>
<p><b>Section:</b> X 15.36 [fs.op.system_complete] <b>Status:</b> <a href="n4095.html#WP">WP</a>
 <b>Submitter:</b> FI-10 <b>Opened:</b> 2014-01-20 <b>Last modified:</b> 2014-06-27</p>
<p><b>View all issues with</b> <a href="status-index.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>"[Example: For POSIX based operating systems, <tt>system_complete(p)</tt>
has the same semantics as <tt>complete(p, current_path())</tt>." What is this
<tt>complete</tt> that is referred here?</p>

<p>Clarify the example.</p>

<p><i>[2014-02-10 Beman Dawes suggests wording]</i></p>


  <p><i>[2014-02-13 LWG/SG-3 Issaquah: Proposed wording accepted.]</i></p>




<p><b>Proposed resolution:</b></p>
  <p>
  <i>Change 15.36 [fs.op.system_complete]:</i>
  </p> 
  <blockquote>
    [<i>Example:</i> For POSIX based operating systems, <code>system_complete(p)</code>
    has the same semantics as <code>
      <del>complete</del><ins>absolute</ins>(p, current_path())</code>.

  </blockquote>






<hr>
<h3><a name="33"></a>33. [PDTS] <tt>unique_path()</tt> is a security vulnerability</h3>
<p><b>Section:</b> X 15.38 [fs.op.unique_path] <b>Status:</b> <a href="n4095.html#WP">WP</a>
 <b>Submitter:</b> CH-19 <b>Opened:</b> 2014-01-20 <b>Last modified:</b> 2014-06-27</p>
<p><b>View all issues with</b> <a href="status-index.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p><tt>unique_path()</tt> is a security vulnerability. As the Linux manual page for the similar
function <tt>tmpnam()</tt> writes in the "BUGS" section: "Never use this function. Use <tt>mkstemp</tt>(3)
or <tt>tmpfile</tt>(3) instead." <tt>mkstemp()</tt> and <tt>tmpfile()</tt> avoid the inherent race condition of
<tt>unique_path()</tt> by returning an open file descriptor or <tt>FILE*</tt>.</p>

<p/><i>[Beman Dawes comments: 10 Feb 2014:]</i>
  <blockquote>
    <p>There are two issues here:</p>
    <ul>
      <li>
        Confusion over what unique_path does and how it is used. The function is
        misleadingly named. These issue have arisen in the past, but apparently not
        been fully corrected. The suggested fix is to (1) rename the function and (2)
        provide an example of how to use the function safely with fstreams or even C I/O.
        See below for proposed wording.
      </li>
      <li>
        Very real security concerns. See <a href="#54">issue 54</a>. The security
        concerns are probably best dealt with in the next File System TS, since a
        full-blown proposal is needed and will likely take several years to develop.
      </li>
    </ul>

  </blockquote>
  
  <p><i>[
    2014-02-11 Issaquah: Strike the function.
  ]</i></p>


  <p><i>[2014-02-12 The following Proposed resolution from CH-19 was moved here
  to avoid confusion with the final Proposed resolution wording from the WG/SG3.]</i></p>

  <p>
    Remove this function. Consider providing a function <tt>create_unique_directory()</tt>.
    If it fits the scope of the proposed TS, consider providing functions
    <tt>create_unique_file()</tt> that returns <tt>ifstream</tt>, <tt>ofstream</tt> and <tt>iofstream</tt>.
  </p>
  <p><i>[
    2014-02-12 The following Proposed wording was moved here
    to avoid confusion with the final Proposed resolution wording from the WG/SG3.
  ]</i></p>

  <p><i>[2014-02-10 Beman Dawes]</i></p>


  <p><strong>Previous resolution from Beman [SUPERSEDED]:</strong></p>
  <blockquote class="note">
  <p>
  <i>Change 15.38 [fs.op.unique_path]:</i>
  </p>
  <pre>
    path <del>unique_path</del><ins>generate_random_filename</ins>(const path&amp; model=&quot;%%%%-%%%%-%%%%-%%%%&quot;);
    path <del>unique_path</del><ins>generate_random_filename</ins>(const path&amp; model, error_code&amp; ec);
  </pre>
  <blockquote>
    <p>
      The <code>
        <del>unique_path</del>
        <ins>generate_random_filename</ins>
      </code> function generates a name suitable for temporary files, including directories. The name is based
      on a model that uses the percent sign character to specify replacement by a
      random hexadecimal digit.
    </p>
    <p>
      [<i>Note:</i> The more bits of randomness in the
      generated name, the less likelihood of prior existence or being guessed.
      Each replacement hexadecimal digit in the model adds four bits of randomness.
      The default model thus provides 64 bits of randomness. <i>--end note</i>]
    </p>
    <p>
      <i>Returns:</i> A path identical to <code>model</code>, except that each
      occurrence of the percent sign character is replaced by a random hexadecimal
      digit character in the range 0-9, a-f. The signature with argument <code>ec</code>
      returns <code>path()</code> if an error occurs.
    </p>
    <p>
      <i>Throws:</i> As specified in <a href="#Error-reporting">Error reporting</a>.
    </p>
    <p>
      <i>Remarks:</i> Implementations are encouraged to obtain the required
      randomness via a <a href="http://en.wikipedia.org/wiki/Cryptographically_secure_pseudorandom_number_generator">cryptographically secure pseudo-random number generator</a>, such as one
      provided by the operating system. [<i>Note</i>: Such generators may block
      until sufficient entropy develops. <i>--end note</i>]
    </p>
    <p>
      <p>
        <i>
          <span style="background-color: #e0e0e0">
            Replace this example with one
            that opens a std::ofstream:
          </span>
        </i>
      </p>
      [<i>Example</i>:
    </p>
    <blockquote>
      <pre>
        cout &lt;&lt; <del>unique_path</del><ins>generate_random_filename</ins>(&quot;test-%%%%%%%%%%%.txt&quot;) &lt;&lt; endl;
      </pre>
    </blockquote>
    <p>
      Typical output would be <code>&quot;test-0db7f2bf57a.txt&quot;</code>. Because 11
      hexadecimal output characters are specified, 44 bits of randomness are
      supplied.&nbsp; <i>-- end example</i>]
    </p>
  </blockquote>
</blockquote>



<p><b>Proposed resolution:</b></p>

  <p/>Remove the two <code>unique_path</code> function signatures from 6 [fs.filesystem.synopsis].

  <p/>Remove 15.38 [fs.op.unique_path] in its entirety.
  
  <p><i>[This removes all references the function from the working draft.]</i></p>

 





<hr>
<h3><a name="34"></a>34. 
    [PDTS] <tt>enum class directory_options</tt> has no summary
  </h3>
<p><b>Section:</b> X 6 [fs.filesystem.synopsis] <b>Status:</b> <a href="n4095.html#WP">WP</a>
 <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2014-01-30 <b>Last modified:</b> 2014-07-04</p>
<p><b>View all other</b> <a href="section-index.html# [fs.filesystem.synopsis">issues</a> in 6 [fs.filesystem.synopsis].</p>
<p><b>View all issues with</b> <a href="status-index.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p><tt>enum class directory_options</tt> has no summary.</p>


<p><b>Proposed resolution:</b></p>

  <p>
    <i>Change 6 [fs.filesystem.synopsis]:</i>
  </p>
  <blockquote>
    <pre>
      enum class directory_options<ins>;</ins>
      <del>{</del>
      <del>none,</del>
      <del>follow_directory_symlink,</del>
      <del>skip_permission_denied</del>
      <del>};</del></pre>
  </blockquote>
  <p>
    <i>Add the following sub-section:</i>
  </p>
  <blockquote>

    <h3>
      10.4  Enum class <code>directory_options</code> [<a name="enum.directory_options">enum.directory_options</a>]
    </h3>
    <p>
      The <tt>enum class</tt> type <code>directory_options</code>
      is a bitmask type (C++11 §17.5.2.1.3) that specifies bitmask constants used to identify
      directory traversal options.
    </p>
    <table border="1" cellpadding="5" cellspacing="0" style="border-collapse: collapse" bordercolor="#111111">
      <tr>
        <td>
          <b>Name</b>
        </td>
        <td align="center">
          <b>Value</b>
        </td>
        <td>
          <b>Meaning</b>
        </td>
      </tr>

      <tr>
        <td>
          <code>none</code>
        </td>
        <td align="center">
          <code>0</code>
        </td>
        <td>(Default) Skip directory symlinks, permission denied is error.</td>
      </tr>
      <tr>
        <td>
          <code>follow_directory_symlink</code>
        </td>
        <td align="center">
          <code>1</code>
        </td>
        <td> Follow rather than skip directory symlinks.</td>
      </tr>
      <tr>
        <td>
          <code>skip_permission_denied</code>
        </td>
        <td align="center">
          <code>2</code>
        </td>
        <td> Skip directories that would otherwise result in permission denied errors.</td>
      </tr>

    </table>
  </blockquote>





<hr>
<h3><a name="35"></a>35. [PDTS] <tt>directory_options::skip_permission_denied</tt> is not used</h3>
<p><b>Section:</b> X 6 [fs.filesystem.synopsis] <b>Status:</b> <a href="n4095.html#WP">WP</a>
 <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2014-01-30 <b>Last modified:</b> 2014-07-04</p>
<p><b>View all other</b> <a href="section-index.html# [fs.filesystem.synopsis">issues</a> in 6 [fs.filesystem.synopsis].</p>
<p><b>View all issues with</b> <a href="status-index.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<tt>directory_options::skip_permission_denied</tt> is not used.
</p>
  <p><i>[2014-04-13 Beman: <tt>skip_permissions_denied</tt> not being used is a
  symptom of a more serious problem; two <tt>directory_itorator</tt> constructors
  are missing <tt>directory_options</tt> arguments and a description of how they
  are used. Proposed wording provided.]</i></p>

  <p><i>[17 Jun 2014 LWG requests two signatures rather than one with default argument. Beman updates wording.]</i></p>



<p><b>Proposed resolution:</b></p>
  <p>
    <i>Change 13  [class.directory_iterator]:</i>
  </p>
  <blockquote>
    <pre>
      directory_iterator() noexcept;
      explicit directory_iterator(const path&amp; p);
      <ins>directory_iterator(const path&amp; p, directory_options options</ins>);
      directory_iterator(const path&amp; p, error_code&amp; ec) noexcept;
      <ins>directory_iterator(const path&amp; p,</ins>
      <ins>directory_options options, error_code&amp; ec) noexcept;</ins>
      directory_iterator(const directory_iterator&amp;) = default;
      directory_iterator(directory_iterator&amp;&amp;) = default;
      ~directory_iterator();
    </pre>
  </blockquote>
  <p>
    <i>Change 13.1 directory_iterator members [directory_iterator.members]:</i>
  </p>
  <blockquote>
    <pre>
      explicit directory_iterator(const path&amp; p);
      <ins>directory_iterator(const path&amp; p, directory_options options</ins>);
      directory_iterator(const path&amp; p, error_code&amp; ec) noexcept;
      <ins>directory_iterator(const path&amp; p,</ins>
      <ins>directory_options options, error_code&amp; ec) noexcept;</ins>
    </pre>
    <p>
      <i>Effects:</i> For the directory that <code>p</code> resolves to,
      constructs an iterator for the first element in a sequence of <code>
        directory_entry
      </code> elements representing the files in the directory, if
      any; otherwise the end iterator.
    </p>
    <p>
      <ins>
        However, if <code>options &amp; directory_options::skip_permissions_denied != directory_options::none</code>
        and construction encounters an error indicating that permission to access&nbsp;
        <code>p</code> is denied, constructs the end iterator and does not report an
        error.
      </ins>
    </p>
  </blockquote>
  <p>
    <i>
      Change 14  <a name="Class-recursive_directory_iterator">
        Class <code>recursive_directory_iterator</code>
        [class.rec.dir.itr]
      </a>:
    </i>
  </p>
  <blockquote>
    <pre>
      explicit recursive_directory_iterator(const path&amp; p<del>,</del>
      <del>directory_options options = directory_options::none</del>);
      <ins>recursive_directory_iterator(const path&amp; p, directory_options options);</ins>
      recursive_directory_iterator(const path&amp; p,
      directory_options options, error_code&amp; ec) noexcept;
      recursive_directory_iterator(const path&amp; p, error_code&amp; ec) noexcept;
    </pre>
  </blockquote>
  <p>
    <i>Change 14.1 recursive_directory_iterator members [rec.dir.itr.members]:</i>
  </p>
  <blockquote>
    <pre>
      explicit recursive_directory_iterator(const path&amp; p<del>,</del>
      <del>directory_options options = directory_options::none</del>);
      <ins>recursive_directory_iterator(const path&amp; p, directory_options options);</ins>
      recursive_directory_iterator(const path&amp; p,
      directory_options options, error_code&amp; ec) noexcept;
      recursive_directory_iterator(const path&amp; p, error_code&amp; ec) noexcept;
    </pre>
    <p>
      <i>Effects:</i>&nbsp; Constructs a iterator representing the first entry in the
      directory <code>p</code> resolves to, if any; otherwise, the end iterator.
    </p>
    <p>
      <ins>
        However, if <code>options &amp; directory_options::skip_permissions_denied != directory_options::none</code>
        and construction encounters an error indicating that permission to access&nbsp;
        <code>p</code> is denied, constructs the end iterator and does not report an
        error.
      </ins>
    </p>
  </blockquote>
  <p>
    <i>Change 14.1 recursive_directory_iterator members [rec.dir.itr.members]:</i>
  </p>
  <blockquote>
    <pre>
      recursive_directory_iterator&amp; operator++();
      recursive_directory_iterator&amp; increment(error_code&amp; ec);
    </pre>
    <p>
      <i>Requires:</i> <code>*this != recursive_directory_iterator()</code>.
    </p>
    <p>
      <i>Effects:</i> As specified by C++11 § 24.1.1 Input iterators, except
      that:
    </p>
    <ul>
      <li>
        If there are no more entries at this depth, then if <code>depth()!= 0</code>
        iteration over the parent directory resumes; otherwise <code>
          *this =
          recursive_directory_iterator()
        </code>.
      </li>
      <li>
        Otherwise if <code>
          recursion_pending() &amp;&amp; is_directory(this-&gt;status())
          &amp;&amp; (!is_symlink(this-&gt;symlink_status()) || (options() &amp;
          directory_options::follow_directory_symlink) != <del>0</del> <ins>directory_options::none</ins>)
        </code> then <ins>either</ins> directory
        <code>(*this)-&gt;path()</code> is recursively iterated into
        <ins>
          or, if <code>
            options() &amp; directory_options::skip_permissions_denied != directory_options::none
          </code>
          and an error occurs indicating that permission to access directory
          <code>(*this)-&gt;path()</code> is denied, then directory <code>(*this)-&gt;path()</code> is
          treated as an empty directory and no error is reported
        </ins>.
      </li>
    </ul>
  </blockquote>





<hr>
<h3><a name="36"></a>36. [PDTS] <tt>copy_options::copy_symlinks</tt> is not used</h3>
<p><b>Section:</b> X 10.2 [enum.copy_options] <b>Status:</b> <a href="n4095.html#WP">WP</a>
 <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2014-01-30 <b>Last modified:</b> 2014-07-04</p>
<p><b>View all other</b> <a href="section-index.html#0.2 [enum.copy_options">issues</a> in 10.2 [enum.copy_options].</p>
<p><b>View all issues with</b> <a href="status-index.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<tt>copy_options::copy_symlinks</tt> is not used (should test it before calling <tt>copy_symlinks</tt> in <tt>copy</tt>).
</p>
  <p><i>[20 May 2014 Beman Dawes provides proposed wording.]</i></p>



<p><b>Proposed resolution:</b></p>
  <p>
    <i>Change 15.3 Copy [fs.op.copy]:</i>
  </p>
  <blockquote>
    <blockquote>
      <p>
        If <code>is_symlink(f)</code>, then:
      </p>
      <ul>
        <li>
          If <code>options &amp; copy_options::skip_symlinks</code>, then return.&nbsp;
          <span style="font-style: italic; background-color: #C0C0C0">Missing != copy_options::none fixed by issue 59</span>
        </li>
        <li>
          Otherwise if <code>
            !exists(t) <ins>
              &amp;&amp; (options &amp; copy_options::copy_symlinks)
              != copy_options::none
            </ins>
          </code>, then <code>
            copy_symlink(from,
            to, options)
          </code>.
        </li>
        <li>
          Otherwise report an error as specified in
          <a href="file:///C:/dot16/filesystem-ts/issues/mailing/active.html#Error-reporting"
           style="color: #2020FF; text-decoration: none">
            Error reporting (7)
          </a>.
        </li>
      </ul>
    </blockquote>
  </blockquote>





<hr>
<h3><a name="37"></a>37. [PDTS] All functions with <tt>error_code</tt> arguments should be <tt>noexcept</tt></h3>
<p><b>Section:</b> X 15.2 [fs.op.canonical], X 15.11 [fs.op.current_path], X 15.27 [fs.op.read_symlink], X 15.36 [fs.op.system_complete], X 15.37 [fs.op.temp_dir_path], X 15.38 [fs.op.unique_path], X 8.4 [path.member] <b>Status:</b> <a href="n4095.html#WP">WP</a>
 <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2014-01-30 <b>Last modified:</b> 2014-07-04</p>
<p><b>View all issues with</b> <a href="status-index.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
all functions with <tt>error_code</tt> arguments should be <tt>noexcept</tt>
(see <tt>canonical</tt>, <tt>current_path</tt>, <tt>read_symlink</tt>, <tt>system_complete</tt>,
<tt>temp_directory_path</tt>, <tt>unique_path</tt>, plus member functions).
</p>
<p><i>[2014-02-03: Stephan T. Lavavej comments:]</i></p>
<p>The declaration and definition of
"<tt>recursive_directory_iterator&amp; increment(error_code&amp; ec);</tt>" should almost certainly
be marked noexcept.</p>

<p><i>[2014-02-08: Daniel comments]</i></p>

<p>
All functions that return a <tt>path</tt> value such as <tt>canonical</tt>, <tt>current_path</tt>,
<tt>read_symlink</tt>, <tt>system_complete</tt>, <tt>temp_directory_path</tt>, <tt>unique_path</tt>,
or any member function returning a <tt>path</tt> value or <tt>basic_string</tt> value might legally 
throw an exception, if the allocator of the underlying string complains about insufficient 
memory. This is an anti-pattern for <tt>noexcept</tt>, because the exception-specification includes 
the return statement of a function and given the fact that the language currently does declare RVO
as an optional action, we cannot rely on it.
<p/>
The Standard is currently very careful <em>not</em> to specify functions as <tt>noexcept</tt>,
if this case can happen, see e.g. <tt>std::locale::name()</tt>. To the contrary, enforcing them to be
<tt>noexcept</tt>, would cause a similar problem as the unconditional <tt>noexcept</tt> specifier of
the value-returning <tt>kill_dependency</tt> as denoted by LWG 2236.
<p/>
Basically this requirement conflicts with the section "Adopted Guidelines", second bullet of
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3279.pdf">N3279</a>.
</p>

<p><i>[Beman Dawes 2014-02-27]</i></p>


<p/>Issues <a href="active.html#37">37</a>,
<a href="active.html#38">38</a>,
<a href="active.html#41">41</a>,
and <a href="active.html#49">49</a> are concerned with signatures which should or should not
be <tt>noexcept</tt>. I will provide unified proposed wording for these issues, possibly in a separate paper.

<p><i>[21 May 2014 Beman Dawes reviewed all functions with <code>error_code&amp;</code> arguments,
  and provided proposed wording for the one case found where the above guidelines were not met.
  This was the case previously identified by Stephan T. Lavavej.
]</i></p>




<p><b>Proposed resolution:</b></p>
  <p>
    <i>Change 14 Class recursive_directory_iterator [class.rec.dir.itr]:</i>
  </p>
  <blockquote>
    <pre>recursive_directory_iterator&amp; increment(error_code&amp; ec) <ins>noexcept</ins>;</pre>
  </blockquote>
  <p>
    <i>Change 14.1 recursive_directory_iterator members [rec.dir.itr.members]:</i>
  </p>
  <blockquote>
    <pre>recursive_directory_iterator&amp; increment(error_code&amp; ec) <ins>noexcept</ins>;</pre>
  </blockquote>





<hr>
<h3><a name="40"></a>40. [PDTS] <tt>class directory_entry</tt> should retain <tt>operator const path&amp;()</tt> from V2</h3>
<p><b>Section:</b> X 12 [class.directory_entry] <b>Status:</b> <a href="n4095.html#WP">WP</a>
 <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2014-01-30 <b>Last modified:</b> 2014-07-04</p>
<p><b>View all other</b> <a href="section-index.html#2 [class.directory_entry">issues</a> in 12 [class.directory_entry].</p>
<p><b>View all issues with</b> <a href="status-index.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>  
<tt>class directory_entry</tt> should retain <tt>operator const path&amp;()</tt> from V2.
</p>

  <p><i>[2014-05-19 Beman Dawes supplied proposed wording.]</i></p>

  <p><i>[2014-06-02 Beman Dawes provides rationale:]</i></p>

  <blockquote>
    This conversion operator was removed when <code>status()</code> and <code>symlink_status()</code>
    were added during the transition from V2 to V3 as it seemed a bit unusual to have a conversion
    operator for one of the several values held. Users complained as they had found the
    automatic conversion convenient in the most common <code>directory_entry</code> use case.
  </blockquote>
  <p><i>[17 Jun 2014 Rapperswil LWG discusses in depth, accepts proposed wording.]</i></p>
  


<p><b>Proposed resolution:</b></p>
  <p>
    <i>Change 12 Class directory_entry [class.directory_entry]:</i>
  </p>
  <blockquote>
    <pre>// observers
const path&amp;  path() const noexcept;
<ins>operator const path&amp;() const noexcept;</ins>
file_status  status() const;
file_status  status(error_code&amp; ec) const noexcept;
file_status  symlink_status() const;
file_status  symlink_status(error_code&amp; ec) const noexcept;</pre>
  </blockquote>

  <p>
    <i>Change 12.3 directory_entry observers [directory_entry.obs]:</i>
  </p>
  <blockquote>
    <pre>const path&amp; path() const noexcept;
<ins>operator const path&amp;() const noexcept;</ins></pre>
    <blockquote>
      <p>
        <i>Returns:</i>
        <code>m_path</code>
      </p>
    </blockquote>
  </blockquote>






<hr>
<h3><a name="41"></a>41. [PDTS] <tt>directory_iterator</tt>, <tt>recursive_directory_iterator</tt>, move construct/assign should be <tt>noexcept</tt></h3>
<p><b>Section:</b> X 13 [class.directory_iterator], X 14 [class.rec.dir.itr] <b>Status:</b> <a href="n4095.html#WP">WP</a>
 <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2014-01-30 <b>Last modified:</b> 2014-07-04</p>
<p><b>View all other</b> <a href="section-index.html#3 [class.directory_iterator">issues</a> in 13 [class.directory_iterator].</p>
<p><b>View all issues with</b> <a href="status-index.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<tt>class directory_iterator</tt> move construct/assign should be <tt>noexcept</tt>.<br/>
<tt>class recursive_directory_iterator</tt> move construct/assign should be <tt>noexcept</tt>.
</p>

<p><i>[Beman Dawes 2014-02-27]</i></p>


  <p/>Issues <a href="active.html#37">37</a>,
  <a href="active.html#38">38</a>,
  <a href="active.html#41">41</a>,
  and <a href="active.html#49">49</a> are concerned with signatures which should or should not
  be <tt>noexcept</tt>. I will provide unified proposed wording for these issues, possibly in a separate paper.
  <p><i>[Daniel Krügler 2014-02-28]</i></p>


<pre>directory_iterator begin(directory_iterator iter) noexcept;
directory_iterator end(const directory_iterator&amp;) noexcept;</pre>

<p/>are noexcept, but we have no guarantee that at least the
move-constructor is noexcept:

<pre>directory_iterator(const directory_iterator&amp;) = default;
directory_iterator(directory_iterator&amp;&amp;) = default;</pre>

<p/>This means that either the above noexcept specifications are not
warranted or that at least the move-constructor of <tt>directory_iterator</tt>
is required to be noexcept.

<p/>The same applies to <tt>recursive_directory_iterator</tt>.

<p><i>[21 May 2014 Beman Dawes provided proposed resolution wording.]</i></p>

  <p><i>[18 Jun 2014 "= default" removed per LWG discussion]</i></p>



<p><b>Proposed resolution:</b></p>
<p>
  <i>Change 13 Class directory_iterator [class.directory_iterator]:</i></p>
  <blockquote>
    <pre>directory_iterator(const directory_iterator&amp; <ins>rhs</ins>) <del>= default</del>;
directory_iterator(directory_iterator&amp;&amp; <ins>rhs</ins>) <ins>noexcept</ins> <del>= default</del>;
...
directory_iterator&amp; operator=(const directory_iterator&amp; <ins>rhs</ins>) <del>= default</del>;
directory_iterator&amp; operator=(directory_iterator&amp;&amp; <ins>rhs</ins>) <ins>noexcept</ins> <del>= default</del>;</pre>
  </blockquote>

  <p/><i>To 13.1 directory_iterator members [directory_iterator.members] add:</i>
  <blockquote>
    <pre>directory_iterator(const directory_iterator&amp; rhs);
directory_iterator(directory_iterator&amp;&amp; rhs) noexcept;</pre>
    <blockquote>
      <p>
        <i>Effects:</i> Constructs an object of class <code>directory_iterator</code>.
      </p>
      <p>
        <i>Postconditions:</i> <code>*this</code> has the original value of <code>rhs</code>.
      </p>

    </blockquote>
    <pre>directory_iterator&amp; operator=(const directory_iterator&amp; rhs);
directory_iterator&amp; operator=(directory_iterator&amp;&amp; rhs) noexcept;</pre>
    <blockquote>
      <p>
        <i>Effects:</i>  
        If <code>*this</code> and <code>rhs</code> are the same object, the member has no effect.
      </p>
      <p>
        <i>Postconditions:</i> <code>*this</code> has the original value of <code>rhs</code>.
      </p>
      <p/><i>Returns:</i>
      <code>*this</code>.

    </blockquote>
  </blockquote>

  <p>
    <i>Change 14 Class recursive_directory_iterator [class.rec.dir.itr]:</i>
  </p>
  <blockquote>
    <pre>recursive_directory_iterator(const recursive_directory_iterator&amp; <ins>rhs</ins>) <del>= default</del>;
recursive_directory_iterator(recursive_directory_iterator&amp;&amp; <ins>rhs</ins>) <ins>noexcept</ins> <del>= default</del>;
...
recursive_directory_iterator&amp; operator=(const recursive_directory_iterator&amp; <ins>rhs</ins>) <del>= default</del>;
recursive_directory_iterator&amp; operator=(recursive_directory_iterator&amp;&amp; <ins>rhs</ins>) <ins>noexcept</ins> <del>= default</del>;</pre>
  </blockquote>
  <p/>
  <i>To 14.1 recursive_directory_iterator members [rec.dir.itr.members] add:</i>
  <blockquote>
    <pre>recursive_directory_iterator(const recursive_directory_iterator&amp; rhs);</pre>
    <blockquote>
      <p>
        <i>Effects:</i> Constructs an object of class <code>recursive_directory_iterator</code>.
      </p>
      <p>
        <i>Postconditions:</i> <code>this->options() == rhs.options() &amp;&amp; this->depth() ==
        rhs.depth() &amp;&amp; this->recursion_pending() ==
        rhs.recursion_pending()</code>.
      </p>
    </blockquote>

    <pre>recursive_directory_iterator(recursive_directory_iterator&amp;&amp; rhs) noexcept;</pre>
    <blockquote>
      <p>
        <i>Effects:</i> Constructs an object of class <code>recursive_directory_iterator</code>.
      </p>
      <p>
        <i>Postconditions:</i> <code>this->options()</code>, <code>this->depth()</code>, and
        <code>this->recursion_pending()</code> return the values that
        <code>rhs.options()</code>, <code>rhs.depth()</code>, and <code>rhs.recursion_pending()</code>,
        respectively, had before the function call.
      </p>
    </blockquote>

    <pre>recursive_directory_iterator&amp; operator=(const recursive_directory_iterator&amp; rhs);</pre>
    <blockquote>
      <p>
        <i>Effects:</i> 
        If <code>*this</code> and <code>rhs</code> are the same object, the member has no effect.
      </p>
      <p>
      <i>Postconditions:</i> <code>
        this->options() == rhs.options() &amp;&amp; this->depth() ==
        rhs.depth() &amp;&amp; this->recursion_pending() ==
        rhs.recursion_pending()
      </code>.
      </p>

      <p/><i>Returns:</i>
      <code>*this</code>.

    </blockquote>

    <pre>recursive_directory_iterator&amp; operator=(recursive_directory_iterator&amp;&amp; rhs) noexcept;</pre>
    <blockquote>
      <p>
        <i>Effects:</i> 
        If <code>*this</code> and <code>rhs</code> are the same object, the member has no effect.
      </p>
      <p>
        <i>Postconditions:</i>
        <code>this->options()</code>, <code>this->depth()</code>, and
        <code>this->recursion_pending()</code> return the values that
        <code>rhs.options()</code>, <code>rhs.depth()</code>, and <code>rhs.recursion_pending()</code>,
        respectively, had before the function call.
      </p>
      <p/><i>Returns:</i> <code>*this</code>.

    </blockquote>
  </blockquote>







<hr>
<h3><a name="44"></a>44. [PDTS] enum classes <tt>copy_options</tt> and <tt>perms</tt> should be bitmask types</h3>
<p><b>Section:</b> X 10.2 [enum.copy_options], X 10.3 [enum.perms] <b>Status:</b> <a href="n4095.html#WP">WP</a>
 <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2014-01-30 <b>Last modified:</b> 2014-06-27</p>
<p><b>View all other</b> <a href="section-index.html#0.2 [enum.copy_options">issues</a> in 10.2 [enum.copy_options].</p>
<p><b>View all issues with</b> <a href="status-index.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
enum classes <tt>copy_options</tt> and <tt>perms</tt> should be bitmask types.
</p>

<p><i>[2014-02-08 Daniel comments and suggests wording]</i></p>

<p>
Since both enum types contain enumeration values that denote the value zero, they are currently not
allowed to be described as <i>bitmask types</i>. This issue depends on LWG issue 1450, which &mdash; if it would
be accepted &mdash; would allow for applying this concept to these enumeration types.
</p>

  <p><i>[2014-02-13 LWG/SG-3 Issaquah: Proposed wording accepted.]</i></p>




<p><b>Proposed resolution:</b></p>
<p>This wording is relative to <a href="http://wiki.edg.com/twiki/pub/Wg21issaquah/SG3/working-draft.html">SG3 working draft</a> <em>and 
assumes that LWG 1450 has been resolved</em>.</p>

<ol>
<li><p>Change [enum.copy_options] as indicated:</p>
<blockquote><p>
<del>This enumeration</del><ins>The <tt>enum class</tt> type <tt>copy_options</tt> is a bitmask type (C++11 &sect;17.5.2.1.3) that</ins> 
specifies bitmask constants used to control the semantics of copy operations. The constants are specified in option groups. [&hellip;]
</p></blockquote>
</li>

<li><p>Change [enum.perms] as indicated:</p>
<blockquote><p>
<del>This enumeration</del><ins>The <tt>enum class</tt> type <tt>perms</tt> is a bitmask type (C++11 &sect;17.5.2.1.3) that</ins> 
specifies bitmask constants used to identify file permissions.
</p></blockquote>
</li>
</ol>





<hr>
<h3><a name="45"></a>45. 
[PDTS] <tt>create_directory</tt> should refer to <tt>perms::all</tt> instead of Posix
<tt>S_IRWXU|S_IRWXG|S_IRWXO</tt>
</h3>
<p><b>Section:</b> X 15.7 [fs.op.create_directory] <b>Status:</b> <a href="n4095.html#WP">WP</a>
 <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2014-01-30 <b>Last modified:</b> 2014-07-04</p>
<p><b>View all issues with</b> <a href="status-index.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<tt>create_directory</tt> should refer to <tt>perms::all</tt> instead of the Posix
<tt>S_IRWXU|S_IRWXG|S_IRWXO</tt>.
</p>
<p><i>[2014-02-28 Beman provided proposed wording.]</i></p>



<p><b>Proposed resolution:</b></p>
<p><i>Effects:</i> Establishes the postcondition by attempting to create the 
  directory <code>p</code> resolves to, as if by POSIX <code>
  mkdir()</code> with a second argument of <del>S_IRWXU|S_IRWXG|S_IRWXO</del> <ins><code>static_cast&lt;int&gt;(perms::all)</code></ins>. Creation 
  failure because <code>p</code> resolves to an existing directory shall not be 
  treated as an error. </p>






<hr>
<h3><a name="47"></a>47. [PDTS] <tt>last_write_time()</tt> uses ill-formed cast</h3>
<p><b>Section:</b> X 15.25 [fs.op.last_write_time] <b>Status:</b> <a href="n4095.html#WP">WP</a>
 <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2014-01-30 <b>Last modified:</b> 2014-06-27</p>
<p><b>View all other</b> <a href="section-index.html#5.25 [fs.op.last_write_time">issues</a> in 15.25 [fs.op.last_write_time].</p>
<p><b>View all issues with</b> <a href="status-index.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In <tt>last_write_time</tt>, <tt>static_cast&lt;file_time_type&gt;(-1)</tt> is ill formed,
(possibly should be <tt>chrono&lt;<i>unspecified-trivial-clock</i>&gt;::from_time_t(-1))</tt>.
</p>

<p><i>[2014-02-08 Daniel comments and provides wording]</i></p>


<p>
I agree that the current wording needs to be fixed, but it is unclear to me whether invoking
<tt>from_time_t</tt> (which is only guaranteed to exist for <tt>std::chrono::system_clock</tt>)
with a value of <tt>time_t(-1)</tt> is a well-defined operation. Reason is that the C Standard
makes a difference between a <i>calendar time</i> and the value <tt>time_t(-1)</tt> as an error 
indication. But the specification of <tt>system_clock::from_time_t</tt> only says "A <tt>time_point</tt> 
object that represents the same point in time as <tt>t</tt> [&hellip;]" and it is not clear whether
<tt>time_t(-1)</tt> can be considered as a "point in time". Instead of relying on such a potentially
subtle semantics of the conversion result of <tt>time_t(-1)</tt> to <tt>std::chrono::system_clock::time_point</tt>
with a further conversion to <tt>file_time_type</tt> (which in theory could led to overflow or underflow and
thus another potential source of undefined behaviour), I suggest to change the current error value of
<tt>last_write_time</tt> to one of the well-define limiting values of <tt>file_time_type</tt>, e.g.
<tt>file_time_type::min()</tt>.
</p>

  <p><i>[2014-02-13 LWG/SG-3 Issaquah: Proposed wording accepted.]</i></p>




<p><b>Proposed resolution:</b></p>
<p>This wording is relative to <a href="http://wiki.edg.com/twiki/pub/Wg21issaquah/SG3/working-draft.html">SG3 working draft</a>.</p>

<ol>
<li><p>Change the last write time prototype specification, 15.25 [fs.op.last_write_time], as indicated:</p>
<blockquote><pre>
file_time_type last_write_time(const path&amp; p);
file_time_type last_write_time(const path&amp; p, error_code&amp; ec) noexcept;
</pre>
<blockquote>
<p>
<i>Returns</i>: The time of last data modification of <tt>p</tt>, determined as if by the value of the POSIX <tt>stat</tt> 
structure member <tt>st_mtime</tt> obtained as if by POSIX <tt>stat()</tt>. The signature with argument <tt>ec</tt> returns 
<tt><del>static_cast&lt;file_time_type&gt;(-1)</del><ins>file_time_type::min()</ins></tt> if an error occurs.
</p>
</blockquote></blockquote>
</li>
</ol>





<hr>
<h3><a name="48"></a>48. [PDTS] <tt>path::template&lt;class charT&gt;string()</tt> conversion rules</h3>
<p><b>Section:</b> X 8.4.6  [path.native.obs] <b>Status:</b> <a href="n4095.html#WP">WP</a>
 <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2014-01-30 <b>Last modified:</b> 2014-07-04</p>
<p><b>View all issues with</b> <a href="status-index.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<tt>path::template&lt;class charT&gt;string()</tt> should promise to convert by the same
rules as <tt>u16string</tt> for <tt>string&lt;char16_t&gt;</tt>, etc. and one-for-one otherwise.
<p/>
What if <tt>charT</tt> is <tt>signed char</tt> (or even <tt>float</tt>)? I don't see where that choice
is disallowed, so we should either disallow it or make it be something that is quasi-sensible. 
</p>

<p><i>[2014-02-08 Daniel comments]</i></p>

<p>
There are two relevant places in the wording that seem to clarify what is required here:
</p>
<ol>
<li><p>
Most importantly, 5 [fs.req] says:
</p>
<blockquote><p>
Throughout this Technical Specification, <tt>char</tt>, <tt>wchar_t</tt>, <tt>char16_t</tt>, and <tt>char32_t</tt> 
are collectively called <em>encoded character types</em>.
<p/>
Template parameters named <tt>charT</tt> shall be one of the encoded character types.
<p/>
[&hellip;]
[<i>Note</i>: Use of an encoded character type implies an associated encoding. Since <tt>signed char</tt> and <tt>unsigned char</tt> 
have no implied encoding, they are not included as permitted types. &mdash; <i>end note</i>]
</p></blockquote>
</li>

<li><p>
For both the mentioned <tt>string</tt> function template and the specific non-template functions (such as <tt>u16string()</tt>)
the same <tt>Remarks</tt> element exists, that refers to character conversion:
</p>
<blockquote><p>
Conversion, if any, is performed as specified by 8.2 [path.cvt].
</p></blockquote>
</li>
</ol>

<p>
The first quote excludes arbitrary types such as <tt>signed char</tt> or <tt>float</tt> as feasible template arguments. 
The second quote makes clear that both the function template and the non-template functions do normatively refer to the same 
wording in 8.2 [path.cvt].
<p/>
Based on this interpretation of the issue discussion I recommend resolving it as NAD.
<p/>
In addition to that recommendation I recommend to rename the current usage of the symbol <tt>charT</tt> in this technical
specification, because 5 [fs.req] assigns a very special meaning to the constraints on <tt>charT</tt> types that does not
exist to this extend in the rest of the standard library. A similar approach is used in Clause 22, where a special symbol <tt>C</tt>
is used for constrained character types (C++11 &sect;22.3.1.1.1 [locale.category]):
</p>
<blockquote><p>
A template formal parameter with name <tt>C</tt> represents the set of types containing <tt>char</tt>, <tt>wchar_t</tt>, 
and any other implementation-defined character types that satisfy the requirements for a character on which any of the 
<tt>iostream</tt> components can be instantiated.
</p></blockquote>

<p><i>[2014-02-28 Beman provides proposed resolution wording]</i></p>

  <p><i>[18 Jun 2014 Beman changes proposed name from C to EcharT in response to tentative
  vote concern that C was insuficiently informative as a name.]</i></p>




<p><b>Proposed resolution:</b></p>
<p><i>In the entire Working Paper, except in the synopsis for path inserter and extractor and 8.6.1 path inserter and extractor [path.io],
    change each instance of "<code>charT</code>" to "<code>EcharT</code>".</i></p>
<p><i>For example, in 5 [fs.req]:</i></p>
<blockquote>Template parameters named <del><code>charT</code></del> <ins><code>EcharT</code></ins> shall be one of the 
encoded character types.</blockquote>





<hr>
<h3><a name="49"></a>49. [PDTS] <tt>path</tt> and <tt>directory_entry</tt> move ctors should not be <tt>noexcept</tt></h3>
<p><b>Section:</b> X 8.4.1 [path.construct], X 12 [class.directory_entry] <b>Status:</b> <a href="n4095.html#WP">WP</a>
 <b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2014-02-03 <b>Last modified:</b> 2014-07-04</p>
<p><b>View all other</b> <a href="section-index.html#.4.1 [path.construct">issues</a> in 8.4.1 [path.construct].</p>
<p><b>View all issues with</b> <a href="status-index.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<tt>path</tt>'s move ctor is marked <tt>noexcept</tt>, but it contains a <tt>basic_string</tt>.
Similarly, <tt>directory_entry</tt>'s move ctor is marked <tt>noexcept</tt>, but it contains a <tt>path</tt>.
This is affected by LWG 2319 "<tt>basic_string</tt>'s move constructor should not be <tt>noexcept</tt>".
</p>

<p><i>[Beman Dawes 2014-02-27]</i></p>


  <p/>Issues <a href="active.html#37">37</a>,
  <a href="active.html#38">38</a>,
  <a href="active.html#41">41</a>,
  and <a href="active.html#49">49</a> are concerned with signatures which should or should not
  be <tt>noexcept</tt>. I will provide unified proposed wording for these issues, possibly in a separate paper.
  
  <p><i>[21 May 2014 Beman Dawes provides wording.
See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3944.html#2319">LWG 2319</a> for rationale.
]</i></p>


  <p><i>[19 Jun 2014 LWG revises P/R to stay consistent with LWG issues.]</i></p>




<p><b>Proposed resolution:</b></p>
  <i>Change 8 Class path [class.path]:</i>
  <blockquote>
    <pre>path() <ins>noexcept</ins>;</pre>
  </blockquote>

  <i>Change 8.4.1 path constructors [path.construct]:</i>
  <blockquote>
    <pre>path() <ins>noexcept</ins>;</pre>
  </blockquote>

  <i>Change 12 Class directory_entry [class.directory_entry]:</i>
  <blockquote>
    <pre>directory_entry() <ins>noexcept</ins> = default;</pre>
  </blockquote>






<hr>
<h3><a name="50"></a>50. [PDTS] <tt>path::compare(const string&amp; s)</tt> wrong argument type</h3>
<p><b>Section:</b> X 8 [class.path] <b>Status:</b> <a href="n4095.html#WP">WP</a>
 <b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2014-02-03 <b>Last modified:</b> 2014-06-27</p>
<p><b>View all other</b> <a href="section-index.html# [class.path">issues</a> in 8 [class.path].</p>
<p><b>View all issues with</b> <a href="status-index.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<tt>path</tt> has "<tt>int compare(const string&amp; s) const;</tt>" but it should almost certainly take
<tt>const string_type&amp;</tt>, since the third overload takes <tt>const value_type*</tt>.
</p>

<p><i>[2014-02-08 Daniel comments and provides wording]</i></p>


<p>
This issue is the same as <a href="n4096.html#43">43</a> and resolves that issue as well.
</p>

  <p><i>[2014-02-13 LWG/SG-3 Issaquah: Proposed wording accepted.]</i></p>




<p><b>Proposed resolution:</b></p>
<p>This wording is relative to <a href="http://wiki.edg.com/twiki/pub/Wg21issaquah/SG3/working-draft.html">SG3 working draft</a>.</p>

<ol>
<li><p>Change class <tt>path</tt> synopsis, 8 [class.path], as indicated:</p>
<blockquote><pre>
<i>// compare</i>
int compare(const path&amp; p) const noexcept;
int compare(const string<ins>_type</ins>&amp; s) const;
int compare(const value_type* s) const;
</pre></blockquote>
</li>

<li><p>Change <tt>path compare</tt> prototype specification, 8.4.8 [path.compare], as indicated:</p>
<blockquote><pre>
int compare(const string<ins>_type</ins>&amp; s) const<ins>;</ins>
</pre></blockquote>
</li>
</ol>





<hr>
<h3><a name="52"></a>52. [PDTS] Better to avoid deriving from <tt>std::iterator</tt></h3>
<p><b>Section:</b> X 13 [class.directory_iterator], X 14 [class.rec.dir.itr] <b>Status:</b> <a href="n4095.html#WP">WP</a>
 <b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2014-02-03 <b>Last modified:</b> 2014-06-27</p>
<p><b>View all other</b> <a href="section-index.html#3 [class.directory_iterator">issues</a> in 13 [class.directory_iterator].</p>
<p><b>View all issues with</b> <a href="status-index.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>Although the Standard has made this mistake almost a dozen times, I recommend not
depicting <tt>directory_iterator</tt> and <tt>recursive_directory_iterator</tt> as deriving from
<tt>std::iterator</tt>, since that's a binding requirement on implementations.
Instead they should be depicted as having the appropriate typedefs, and leave it up to
implementers to decide how to provide them. (The difference is observable to users with
<tt>is_base_of</tt>, not that they should be asking that question.)</p>

<p><i>[2014-02-08 Daniel comments and provides wording]</i></p>

<p>
This issue is basically similar to the kind of solution that had been used to remove the
requirement to derive from <tt>unary_function</tt> and friends as described by
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3198.htm">N3198</a> and
I'm strongly in favour to follow that spirit here as well. I'd like to add that basically all
"newer" iterator types (such as the <tt>regex</tt> related iterator don't derive from
<tt>std::iterator</tt> either.
<p/>
Another reason to change the current specification is the fact that it currently says that
the member types <tt>pointer</tt> and <tt>reference</tt> would be determined to <tt>value_type*</tt>
and <tt>value_type&amp;</tt> (that is mutable pointers and references), which conflicts with the specification 
of the return types of the following members:
</p>
<blockquote><pre>
const directory_entry&amp; operator*() const;
const directory_entry* operator-&gt;() const;
</pre></blockquote>
<p>
The proposed fording fixes this by correcting these <tt>typedef</tt> to corresponding <tt>const</tt> access.
<p/>
The very same objections had been expressed by issue <a href="n4096.html#51">51</a> and the below given wording resolves this
issue as well.
</p>

  <p><i>[2014-02-13 LWG/SG-3 Issaquah: Proposed wording accepted.]</i></p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to <a href="http://wiki.edg.com/twiki/pub/Wg21issaquah/SG3/working-draft.html">SG3 working draft</a>.</p>

<ol>
<li><p>Change class <tt>directory_iterator</tt> synopsis, [class.directory_iterator], as indicated:</p>
<blockquote><pre>
namespace std { namespace tbd { namespace filesystem {

      class directory_iterator <del>:
        public iterator&lt;input_iterator_tag, directory_entry&gt;</del>
      {
      public:
        <ins>typedef directory_entry        value_type;</ins>
        <ins>typedef ptrdiff_t              difference_type;</ins>
        <ins>typedef const directory_entry* pointer;</ins>
        <ins>typedef const directory_entry&amp; reference;</ins>
        <ins>typedef input_iterator_tag     iterator_category;</ins>

        // member functions
        [&hellip;]
      };

} } }  // namespaces std::tbd::filesystem
</pre></blockquote>
</li>

<li><p>Change class <tt>recursive_directory_iterator</tt> synopsis, [class.rec.dir.itr], as indicated:</p>
<blockquote><pre>
namespace std { namespace tbd { namespace filesystem {

      class recursive_directory_iterator <del>:
        public iterator&lt;input_iterator_tag, directory_entry&gt;</del>
      {
      public:
        <ins>typedef directory_entry        value_type;</ins>
        <ins>typedef ptrdiff_t              difference_type;</ins>
        <ins>typedef const directory_entry* pointer;</ins>
        <ins>typedef const directory_entry&amp; reference;</ins>
        <ins>typedef input_iterator_tag     iterator_category;</ins>

        // constructors and destructor
        [&hellip;]
        
        // modifiers
        recursive_directory_iterator&amp; operator=(const recursive_directory_iterator&amp;) = default;
        recursive_directory_iterator&amp; operator=(recursive_directory_iterator&amp;&amp;) = default;
        
        <ins>const directory_entry&amp; operator*() const;</ins>
        <ins>const directory_entry* operator-&gt;() const;</ins>

        recursive_directory_iterator&amp; operator++();
        recursive_directory_iterator&amp; increment(error_code&amp; ec);

        [&hellip;]
      };

} } }  // namespaces std::tbd::filesystem
</pre></blockquote>
</li>
</ol>





<hr>
<h3><a name="53"></a>53. [PDTS] <tt>directory_entry</tt> multithreading concerns</h3>
<p><b>Section:</b> X 12 [class.directory_entry] <b>Status:</b> <a href="n4095.html#WP">WP</a>
 <b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2014-02-03 <b>Last modified:</b> 2014-07-04</p>
<p><b>View all other</b> <a href="section-index.html#2 [class.directory_entry">issues</a> in 12 [class.directory_entry].</p>
<p><b>View all issues with</b> <a href="status-index.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>12 [class.directory_entry] depicts <tt>directory_entry</tt> as having <tt>mutable m_status</tt> and
<tt>m_symlink_status</tt> data members.  This is problematic because of C++11's multithreading
guarantees, which say that <tt>const</tt> member functions are simultaneously callable.
As a result, <tt>mutable</tt> data members must be protected with synchronization, which was
probably not considered during this design.  The complexity and expense may be acceptable
in <tt>directory_entry</tt> (since it can save filesystem queries, apparently) but it would be
very very nice to have a note about this.</p>

  <p><i>[2014-02-13 LWG/SG-3 discussed in Issaquah: Beman and STL will work together to better
  understand the concerns, and to formulate a solution. This is not a blocking issue for
  finishing the TS, but is a blocking issue for merging into the IS]</i></p>

  
  <p><i>[2014-04-17 Beman provides proposed wording]</i></p>

  <p><i>[2014-06-19 Rapperswil LWG decides to remove mutable private members. Beman provides wording.]</i></p>




<p><b>Proposed resolution:</b></p>

  <p/>
  <i>Change 12 [class.directory_entry] as indicated:</i>

  <pre>
    namespace std { namespace experimental { namespace filesystem { inline namespace v1 {

    class directory_entry
    {
    public:

    // <a href="#directory_entry-constructors">constructors</a> and destructor
    directory_entry() = default;
    directory_entry(const directory_entry&amp;) = default;
    directory_entry(directory_entry&amp;&amp;) noexcept = default;
    <ins>explicit directory_entry(const path&amp; p);</ins>
    <del>explicit directory_entry(const path&amp; p, file_status st=file_status(),</del>
      <del>file_status symlink_st=file_status());</del>
    ~directory_entry();

    // <a href="#directory_entry-modifiers">modifiers</a>
    directory_entry&amp; operator=(const directory_entry&amp;) = default;
    directory_entry&amp; operator=(directory_entry&amp;&amp;) noexcept = default;
    <ins>void assign(const path&amp; p);</ins>
    <del>void assign(const path&amp; p, file_status st=file_status()</del>,
      <del>file_status symlink_st=file_status()</del>);
    <ins>void replace_filename(const path&amp; p);</ins>
    <del>void replace_filename(const path&amp; p, file_status st=file_status()</del>,
      <del>file_status symlink_st=file_status()</del>);

    // <a href="#directory_entry-observers">observers</a>
    const path&amp;  path() const noexcept;
    file_status  status() const;
    file_status  status(error_code&amp; ec) const noexcept;
    file_status  symlink_status() const;
    file_status  symlink_status(error_code&amp; ec) const noexcept;

    bool operator&lt; (const directory_entry&amp; rhs) const noexcept;
    bool operator==(const directory_entry&amp; rhs) const noexcept;
    bool operator!=(const directory_entry&amp; rhs) const noexcept;
    bool operator&lt;=(const directory_entry&amp; rhs) const noexcept;
    bool operator&gt; (const directory_entry&amp; rhs) const noexcept;
    bool operator&gt;=(const directory_entry&amp; rhs) const noexcept;
    private:
    path                 m_path;           // for exposition only
    <del>mutable file_status  m_status;         // for exposition only; stat()-like</del>
    <del>mutable file_status  m_symlink_status; // for exposition only; lstat()-like</del>
    };

    } } } }  // namespaces std::experimental::filesystem::v1
  </pre>
  <p>
    A <code>directory_entry</code> object stores a <code>path</code> object<del>,</del>
    <del>a <code>file_status</code> object for non-symbolic link status, and a <code>file_status</code> object for symbolic link status</del>.
    <del>
      The <code>file_status</code> objects act as value caches.
    </del>
  </p>
  <blockquote>
    <p>
      <del>
        [<i>Note:</i> Because <code>status()</code>on a pathname may be a relatively expensive operation,
        some operating systems provide status information as a byproduct of directory
        iteration. Caching such status information can result in significant time savings. Cached and
        non-cached results may differ in the presence of file system races. <i>&mdash;end note</i>]
      </del>
    </p>
  </blockquote>
  <h3>
    12.1  <a name="directory_entry-constructors">
      <code>directory_entry</code> constructors
    </a>
    [directory_entry.cons]
  </h3>

   <p>
      <i>
        <span style="background-color: #C0C0C0">
          Add the description of this
          constructor in its entirety:
        </span>
      </i>
    </p>
   <pre>explicit directory_entry(const path&amp; p);</pre>
  <blockquote>
    <p/><i>Effects: </i>Constructs an object of type <code>directory_entry</code>
    
    <p>
      <i>Postcondition:</i>
      <code>path() == p</code>.
    </p>

  </blockquote>
  <pre><del>explicit directory_entry(const path&amp; p, file_status st=file_status()</del>,
    <del>file_status symlink_st=file_status()</del>);</pre>
  <blockquote>
    <p>
      <span style="background-color: #C0C0C0">
        <i>Strike the description</i>
      </span>
    </p>

    
  </blockquote>
  <h3>
    12.2  <a name="directory_entry-modifiers">
      <code>directory_entry</code> modifiers
    </a>
    [directory_entry.mods]
  </h3>

  <p>
    <i>
      <span style="background-color: #C0C0C0">
        Add the description of this
        function in its entirety:
      </span>
    </i>
  </p>
  <pre>void assign(const path&amp; p);</pre>
  <blockquote>
    <p>
      <i>Postcondition:</i>
      <code>path() == p</code>.
    </p>
 
  </blockquote>
  <pre><del>void assign(const path&amp; p, file_status st=file_status()</del>,
  <del>file_status symlink_st=file_status());</del></pre>
  <blockquote>
    <p>
      <span style="background-color: #C0C0C0">
        <i>Strike the description</i>
      </span>
    </p>
  </blockquote>

  <p>
    <i>
      <span style="background-color: #C0C0C0">
        Add the description of this
        function in its entirety:
      </span>
    </i>
  </p>
  <pre>void replace_filename(const path&amp; p);</pre>
  <blockquote>
    <p>
      <i>Postcondition:</i> <code>path() == x.parent_path() / p</code>
      where <code>x</code> is the value of <code>path()</code>
      before the function is called.
    </p>
  </blockquote>
  <pre><del>void replace_filename(const path&amp; p, file_status st=file_status()</del>,
  <del>file_status symlink_st=file_status());</del></pre>
  <blockquote>
    <p>
      <span style="background-color: #C0C0C0">
        <i>Strike the description</i>
      </span>
    </p>
  </blockquote>
  <h3>
    12.3  <a name="directory_entry-observers">
      <code>directory_entry</code> observers
    </a>
    [directory_entry.obs]
  </h3>
  <pre>const path&amp; path() const noexcept;</pre>
  <blockquote>
    <p>
      <i>Returns:</i>
      <code>m_path</code>
    </p>
  </blockquote>
  <pre>file_status status() const;
file_status status(error_code&amp; ec) const noexcept;</pre>
  <blockquote>
    <p>
      <del><i>Effects:</i> As if,</del>
    </p>
    <blockquote>
      <pre><del>if (!status_known(m_status))
{
  if (status_known(m_symlink_status) &amp;&amp; !is_symlink(m_symlink_status))
    { m_status = m_symlink_status; }
  else { m_status = status(m_path<i>[, ec]</i>); }
}</del></pre>
    </blockquote>
    <p>
      <i>Returns:</i>
      <code>
        <del>m_status</del>
        <ins>status(path()<i>[, ec]</i>)</ins>
      </code>.
    </p>

    <p>
      <i>Throws:</i> As specified in <a href="#Error-reporting">Error reporting (7)</a>.
    </p>

  </blockquote>
  <pre>file_status  symlink_status() const;
file_status  symlink_status(error_code&amp; ec) const noexcept;</pre>
  <blockquote>
    <p>
      <del><i>Effects:</i> As if,</del>
    </p>
    <blockquote>
      <pre><del>
        if (!status_known(m_symlink_status))
        {
        m_symlink_status = symlink_status(m_path<i>[, ec]</i>);
        }</del></pre>
    </blockquote>
    <p>
      <i>Returns:</i>
      <code>
        <del>m_symlink_status</del>
        <ins>symlink_status(path()<i>[, ec]</i>)</ins>
      </code>.
    </p>

    <p>
      <i>Throws:</i> As specified in <a href="#Error-reporting">Error reporting (7)</a>.
    </p>

  </blockquote>
  <pre>bool operator==(const directory_entry&amp; rhs) const noexcept;</pre>
  <blockquote>
    <p>
      <i>Returns:</i> <code>m_path == rhs.m_path</code>.
    </p>
    <p>
      <del>[<i>Note:</i> Status members do not participate in determining
      equality. — end note]</del>
    </p>
  </blockquote>
  <pre>bool operator!=(const directory_entry&amp; rhs) const noexcept;</pre>
  <blockquote>
    <p>
      <i>Returns:</i> <code>m_path != rhs.m_path</code>.
    </p>
  </blockquote>
  <pre>bool operator&lt; (const directory_entry&amp; rhs) const noexcept;</pre>
  <blockquote>
    <p>
      <i>Returns:</i> <code>m_path &lt; rhs.m_path</code>.
    </p>
  </blockquote>
  <pre>bool operator&lt;=(const directory_entry&amp; rhs) const noexcept;</pre>
  <blockquote>
    <p>
      <i>Returns:</i> <code>m_path &lt;= rhs.m_path</code>.
    </p>
  </blockquote>
  <pre>bool operator&gt; (const directory_entry&amp; rhs) const noexcept;</pre>
  <blockquote>
    <p>
      <i>Returns:</i> <code>m_path &gt; rhs.m_path</code>.
    </p>
  </blockquote>
  <pre>bool operator&gt;=(const directory_entry&amp; rhs) const noexcept;</pre>
  <blockquote>
    <p>
      <i>Returns:</i> <code>m_path &gt;= rhs.m_path</code>.
    </p>
  </blockquote>









<hr>
<h3><a name="55"></a>55. [PDTS] Clarify Error reporting</h3>
<p><b>Section:</b> X 7 [fs.err.report] <b>Status:</b> <a href="n4095.html#WP">WP</a>
 <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2014-01-20 <b>Last modified:</b> 2014-06-27</p>
<p><b>View all issues with</b> <a href="status-index.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
  <p>
    The proposed change below was suggested in Issaquah as part of the resolution of issue 13 to clarify
    the Error reporting section. LWG/SG3 liked the change, but since issue 13 was NAD requested that a separate
    issue be opened.
  </p>

  <p><i>[2014-02-13 LWG/SG-3 Issaquah: Proposed wording accepted.]</i></p>

  


<p><b>Proposed resolution:</b></p>

      <p>
        <i>Change 7 [fs.err.report]:</i>
      </p>

      <blockquote>
        <p>
          Functions <b>not</b> having an argument of type <code>error_code&amp;</code> report errors as follows, unless otherwise specified:
        </p>
        <ul>
          <li>
            When a call by the
            implementation to an operating system or other underlying API results in an
            error that prevents the function from meeting its specifications, an exception
            of type
            <code>filesystem_error</code> shall be thrown. For functions with a single path
            argument, that argument shall be passed to the
            <code>filesystem_error</code> constructor with a single path argument.&nbsp; For
            functions with two path arguments, the first of these arguments shall be
            passed to the
            <code>filesystem_error</code> constructor as the <code>path1</code> argument,
            and the second shall be passed as the <code>path2</code> argument.
            <ins>
              The <code>filesystem_error</code> constructor's <code>error_code</code> argument is set as
              appropriate for the specific operating system dependent error.
            </ins><br/>
            &nbsp;
          </li>
          <li>
            Failure to allocate storage is reported by throwing an exception as described in C++11
            &sect; 17.6.4.10.<br/>
            &nbsp;
          </li>
          <li>Destructors throw nothing.</li>
        </ul>
        <p>
          Functions having an argument of type <code>error_code&amp;</code> report errors as follows, unless otherwise
          specified:
        </p>
        <ul>
          <li>
            If a call by the
            implementation to an operating system or other underlying API results in an
            error that prevents the function from meeting its specifications, the
            <code>error_code&amp;</code> argument is set as
            appropriate for the specific <ins>operating system dependent</ins> error.
            Otherwise, <code>clear()</code> is called on the <code>error_code&amp;</code> argument.
          </li>
        </ul>
      </blockquote>







<hr>
<h3><a name="56"></a>56. [PDTS] Feature test macro for TS version</h3>
<p><b>Section:</b> X 5 [fs.req] <b>Status:</b> <a href="n4095.html#WP">WP</a>
 <b>Submitter:</b> Clark Nelson <b>Opened:</b> 2014-02-10 <b>Last modified:</b> 2014-07-04</p>
<p><b>View all issues with</b> <a href="status-index.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p/><a href="http://isocpp.org/std/standing-documents/sd-6-sg10-feature-test-recommendations">
SD-6: SG10 Feature Test Recommendations</a> recommends that each library header 
provide feature test macros. For Technical Specifications, the TS itself should 
specify recommended names for the feature test macros.
<p><i>[Beman Dawes 2014-02-28 provided the proposed resolution.
Thanks to Vicente J. Botet Escriba, Richard Smith, and Clark Nelson for suggestions and corrections.]</i></p>



<p><b>Proposed resolution:</b></p>
<p><i>Add a new sub-section:</i></p>
<blockquote>
  <p><ins>5.2 Feature test macros [fs.req.macros]</ins></p>
  <p><ins>This macro allows users to determine which version of this Technical Specification
   is supported by header <code>&lt;experimental/filesystem&gt;</code>.</ins></p>
  <p><ins>Header <code>&lt;experimental/filesystem&gt;</code> shall supply the 
  following macro definition:</ins></p>
  <blockquote>
    <pre><ins>#define __cpp_lib_experimental_filesystem     201406</ins></pre>
  </blockquote>
<p><ins>[<i>Note:</i> The value of macro <code>__cpp_lib_experimental_filesystem</code> is
<i>yyyymm</i> where <i>yyyy</i> is the year and <i>mm</i> the month when the version
of the Technical Specification was completed. <i>&mdash; end note</i>]</ins></p>

</blockquote>





<hr>
<h3><a name="57"></a>57. [PDTS] Inappropriate use of "No diagnostic is required"</h3>
<p><b>Section:</b> X 2.1 [fs.conform.9945] <b>Status:</b> <a href="n4095.html#WP">WP</a>
 <b>Submitter:</b> LWG/SG-3 <b>Opened:</b> 2014-02-13 <b>Last modified:</b> 2014-07-04</p>
<p><b>View all other</b> <a href="section-index.html#.1 [fs.conform.9945">issues</a> in 2.1 [fs.conform.9945].</p>
<p><b>View all issues with</b> <a href="status-index.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p/>§ 2.1 [fs.conform.9945] specifes "No diagnostic is required" for races. That prescription is
used by the standard for the core language; it is not appropriate in library specifications.
LWG/SG-3 wishes this be changed to undefined behavior.

<p><i>[Beman comments: The replacment wording is similar to that used by C++14 17.6.4.10]</i></p>



<p><b>Proposed resolution:</b></p>
<p/>Change the following paragraph from § 2.1 [fs.conform.9945]
<blockquote>
<del>The behavior of functions described in this Technical Specification may differ
from their specification in the presence of file system races ([fs.def.race]).
No diagnostic is required.</del>
<p/><ins>Behavior is undefined if calls to functions provided
by this Technical Specification introduce a file system race (4.6 [fs.def.race]).</ins>
</blockquote>

<p/>Insert a new sub-section head before the modified paragraph:
<blockquote>2.1 File system race behavior [fs.race.behavior]</blockquote>






<hr>
<h3><a name="58"></a>58. [PDTS] POSIX <tt>utime()</tt> is obsolescent</h3>
<p><b>Section:</b> X 15.25 [fs.op.last_write_time] <b>Status:</b> <a href="n4095.html#WP">WP</a>
 <b>Submitter:</b> LWG/SG-3 <b>Opened:</b> 2014-02-13 <b>Last modified:</b> 2014-07-04</p>
<p><b>View all other</b> <a href="section-index.html#5.25 [fs.op.last_write_time">issues</a> in 15.25 [fs.op.last_write_time].</p>
<p><b>View all issues with</b> <a href="status-index.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>POSIX now says: "Since the <tt>utimbuf</tt> structure only contains <tt>time_t</tt> variables
and is not accurate to fractions of a second, applications
should use the <tt>utimensat()</tt> function instead of the obsolescent <tt>utime()</tt> function."</p>

  <p>
    Suggested resolution: Rewrite the <tt>last_write_time</tt> setter description to utilize <tt>utimensat() or similar.</tt>
  </p>

  <p><i>[20 May 2014 Beman Dawes supplies proposed wording. He comments:]</i></p>


  <p>POSIX supplies two functions, <code>futimens()</code> and <code>utimensat()</code>,
  as replacements for <code>utime()</code>.
  <code>futimens()</code> is appropriate for the current TS.
  <code>utimensat()</code> will be appropriate for a future File System TS that adds the
  functionality of the whole family of POSIX *<code>at()</code> functions.
</p>



<p><b>Proposed resolution:</b></p>
  <p>
    <i>Change 15.25 Last write time [fs.op.last_write_time]:</i>
  </p>
  <blockquote>
    <p>
      <i>Effects:</i> Sets the time of last data modification of the file resolved
      to by <code>p</code> to <code>new_time</code>, as if by POSIX <del>
        <code>stat()</code>
        followed by POSIX <code>utime()</code>
      </del> <ins>
        <code>futimens()</code>
      </ins>.
    </p>
  </blockquote>





<hr>
<h3><a name="60"></a>60. [PDTS] Incorrect <i>Throws</i> specification for <tt>absolute()</tt></h3>
<p><b>Section:</b> X 15.1 [fs.op.absolute] <b>Status:</b> <a href="n4095.html#WP">WP</a>
 <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2014-02-28 <b>Last modified:</b> 2014-07-04</p>
<p><b>View all issues with</b> <a href="status-index.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>The <i>Throws</i> element [fs.op.absolute] says:</p>
<blockquote>
  <p>&quot;If <code>base.is_absolute()</code> is true, throws only if memory 
  allocation fails.&quot;</p>
</blockquote>
<p>We can strike:</p>
<blockquote>
  <p>&quot;If <code>base.is_absolute()</code> is true,&quot; and the wording will still 
  hold. Note that:</p>
  <ol>
    <li>None of the involved functions has requirements.</li>
    <li>In *every* case potentially memory allocation occurs, even for &quot;<code>return 
    p</code>&quot;, so this allocation can fail.</li>
  </ol>
</blockquote>

<p><i>[02-03-2014 Beman Dawes comments and provides P/R]</i></p>


<p/>The <i>Throws</i> element should follow the same form as similar <i>Throws</i>
elements in the TS. There isn't enough special about this function to justify special
wording and by referencing Error reporting (7) we ensure <tt>absolute()</tt> follows
the overall policy for handling memory allocation failures.



<p><b>Proposed resolution:</b></p>
<p><i>[Change 15.1 [fs.op.absolute]:]</i></p>


<blockquote>
  <p><i>Throws:</i> <del>If <code>base.is_absolute()</code> is true, throws only if 
  memory allocation fails.</del> <ins>As specified in <a href="#Error-reporting">Error reporting (7)</a>.</ins></p>
</blockquote>
  





<hr>
<h3><a name="62"></a>62. Allocator requirements unspecified</h3>
<p><b>Section:</b> X 5 Requirements [fs.req] <b>Status:</b> <a href="n4095.html#WP">WP</a>
 <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2014-05-19 <b>Last modified:</b> 2014-07-04</p>
<p><b>View all issues with</b> <a href="status-index.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
  The SG3 WP refers in several places to a template parameter named "Allocator" but
  does not impose requirements on this type.
</p>


<p><b>Proposed resolution:</b></p>
<p><i>Add the following to 5 Requirements [fs.req]:</i></p>

  <blockquote>
    <p>
      <ins>Template parameters named <code>Allocator</code> shall meet the C++ Standard's
      library Allocator requirements (C++11 §17.6.3.5)</ins></p>
  </blockquote>  





</body>
</html>
