<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
    "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<title>Filesystem Study Group (SG3) Active Issues 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:#E8FFE8}
  del {background-color:#FFD7D7}
</style>
</head>
<body>
<table>
<tr>
  <td align="left">Doc. no.</td>
  <td align="left">N3941</td>
</tr>
<tr>
  <td align="left">Date:</td>
  <td align="left">2014-03-02</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>Filesystem Study Group (SG3) Active Issues List (Revision R0)</h1>
<p>Revised 2014-03-02 at 14:03:36 UTC</p>

  <p>Reference ISO/IEC PDTS 18822</p>
  <p>Also see:</p>
  <ul>
      <li><a href="sg3-toc.html">Table of Contents</a> for all study group issues.</li>
      <li><a href="sg3-index.html">Index by Section</a> for all study group issues.</li>
      <li><a href="sg3-status.html">Index by Status</a> for all study group issues.</li>
      <li><a href="sg3-defects.html">Defect Reports List</a></li>
      <li><a href="sg3-closed.html">Closed Issues List</a></li>
  </ul>
  <p>The purpose of this document is to record the status of issues
  which have come before the File System Study Group (SG-3) of the INCITS PL22.16
  and ISO WG21 C++ Standards Committee. Issues represent
  potential defects in the ISO/IEC PDTS 18822 document.  
  </p>

  <p>This document contains only study group issues which are actively being
  considered by the Study Group, i.e., issues which have a
  status of <a href="sg3-active.html#New">New</a>, <a href="sg3-active.html#Open">Open</a>, 
  <a href="sg3-active.html#Ready">Ready</a>, or <a href="sg3-active.html#Review">Review</a>. See
  <a href="sg3-defects.html">Defect Reports List</a> for issues considered defects and 
  <a href="sg3-closed.html">Closed Issues List</a> for issues considered closed.</p>

  <p>The issues in these lists are not necessarily formal ISO Defect
  Reports (DR's). While some issues will eventually be elevated to
  official Defect Report status, other issues will be disposed of in
  other ways. See <a href="#Status">Issue Status</a>.</p>

 
  <p>This document includes <i>[bracketed italicized notes]</i> as a
  reminder to the SG of current progress on issues. Such notes are
  strictly unofficial and should be read with caution as they may be
  incomplete or incorrect. Be aware that SG support for a particular
  resolution can quickly change if new viewpoints or killer examples are
  presented in subsequent discussions.</p>

  <p>For the most current official version of this document see 
  <a href="http://www.open-std.org/jtc1/sc22/wg21/">http://www.open-std.org/jtc1/sc22/wg21/</a>.
  Requests for further information about this document should include
  the document number above, reference ISO/IEC TS 18822, and be
  submitted to Information Technology Industry Council (ITI), 1250 Eye
  Street NW, Washington, DC 20005.</p>

  <p>Public information as to how to obtain a copy of the C++ Standard,
  join the standards committee, submit an issue, or comment on an issue
  can be found in the comp.std.c++ FAQ.
  </p>

<p><a name="submit_issue"></a><b>How to submit an issue</b></p>

<ol style="list-style-type:upper-alpha">
<li><a name="submit_issue_A"></a>
Mail your issue to the author of this list.
</li>
<li><a name="submit_issue_B"></a>
Specify a short descriptive title.  If you fail to do so, the subject line of your
mail will be used as the issue title.
</li>
<li><a name="submit_issue_C"></a>
If the "From" on your email is not the name you wish to appear as issue submitter,
then specify issue submitter.
</li>
<li><a name="submit_issue_D"></a>
Provide a brief discussion of the problem you wish to correct.  Refer to the latest
working draft or standard using [section.tag] and paragraph numbers where appropriate.
</li>
<li><a name="submit_issue_E"></a>
Provide proposed wording.  This should indicate exactly how you want the standard
to be changed.  General solution statements belong in the discussion area.  This
area contains very clear and specific directions on how to modify the current
draft.  If you are not sure how to word a solution, you may omit this part.
But your chances of a successful issue greatly increase if you attempt wording.
</li>
<li><a name="submit_issue_F"></a>
It is not necessary for you to use html markup.  However, if you want to, you can
&lt;ins&gt;<ins>insert text like this</ins>&lt;/ins&gt; and &lt;del&gt;<del>delete text like
this</del>&lt;/del&gt;.  The only strict requirement is to communicate clearly to
the list maintainer exactly how you want your issue to look.
</li>
<li><a name="submit_issue_G"></a>
It is not necessary for you to specify other html font/formatting
mark-up, but if you do the list maintainer will attempt to respect your
formatting wishes (as described by html markup, or other common idioms).
</li>
<li><a name="submit_issue_H"></a>
It is not necessary for you to specify open date or last modified date (the date
of your mail will be used).
</li>
<li><a name="submit_issue_I"></a>
It is not necessary for you to cross reference other issues, but you can if you
like.  You do not need to form the hyperlinks when you do, the list maintainer will
take care of that.
</li>
<li><a name="submit_issue_J"></a>
One issue per email is best.
</li>
<li><a name="submit_issue_K"></a>
Between the time you submit the issue, and the next mailing deadline
(date at the top of the Revision History), you <em>own</em> this issue. 
You control the content, the stuff that is right, the stuff that is
wrong, the format, the misspellings, etc.  You can even make the issue
disappear if you want.  Just let the list maintainer know how you want
it to look, and he will try his best to accommodate you.  After the
issue appears in an official mailing, you no longer enjoy exclusive
ownership of it.
</li>
</ol>


<h2>Revision History</h2>
<ul>
<li>R0: 2014-03-02 SG-3 File System TS<ul>
<li><b>Summary:</b><ul>
<li>24 open issues, up by 24.</li>
<li>35 closed issues, up by 35.</li>
<li>59 issues total, up by 59.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following 2 Review issues: <a href="sg3-active.html#27">27</a>, <a href="sg3-active.html#57">57</a>.</li>
<li>Added the following 16 New issues: <a href="sg3-active.html#34">34</a>, <a href="sg3-active.html#35">35</a>, <a href="sg3-active.html#36">36</a>, <a href="sg3-active.html#37">37</a>, <a href="sg3-active.html#38">38</a>, <a href="sg3-active.html#40">40</a>, <a href="sg3-active.html#41">41</a>, <a href="sg3-active.html#42">42</a>, <a href="sg3-active.html#45">45</a>, <a href="sg3-active.html#48">48</a>, <a href="sg3-active.html#49">49</a>, <a href="sg3-active.html#54">54</a>, <a href="sg3-active.html#56">56</a>, <a href="sg3-active.html#58">58</a>, <a href="sg3-active.html#59">59</a>, <a href="sg3-active.html#60">60</a>.</li>
<li>Added the following 6 Open issues: <a href="sg3-active.html#4">4</a>, <a href="sg3-active.html#5">5</a>, <a href="sg3-active.html#11">11</a>, <a href="sg3-active.html#22">22</a>, <a href="sg3-active.html#25">25</a>, <a href="sg3-active.html#53">53</a>.</li>
<li>Added the following NAD Future issue: <a href="sg3-closed.html#12">12</a>.</li>
<li>Added the following 22 WP issues: <a href="sg3-defects.html#1">1</a>, <a href="sg3-defects.html#2">2</a>, <a href="sg3-defects.html#3">3</a>, <a href="sg3-defects.html#6">6</a>, <a href="sg3-defects.html#7">7</a>, <a href="sg3-defects.html#8">8</a>, <a href="sg3-defects.html#9">9</a>, <a href="sg3-defects.html#14">14</a>, <a href="sg3-defects.html#15">15</a>, <a href="sg3-defects.html#16">16</a>, <a href="sg3-defects.html#18">18</a>, <a href="sg3-defects.html#19">19</a>, <a href="sg3-defects.html#21">21</a>, <a href="sg3-defects.html#24">24</a>, <a href="sg3-defects.html#29">29</a>, <a href="sg3-defects.html#32">32</a>, <a href="sg3-defects.html#33">33</a>, <a href="sg3-defects.html#44">44</a>, <a href="sg3-defects.html#47">47</a>, <a href="sg3-defects.html#50">50</a>, <a href="sg3-defects.html#52">52</a>, <a href="sg3-defects.html#55">55</a>.</li>
<li>Added the following NAD Editorial issue: <a href="sg3-closed.html#39">39</a>.</li>
<li>Added the following 9 NAD issues: <a href="sg3-closed.html#10">10</a>, <a href="sg3-closed.html#13">13</a>, <a href="sg3-closed.html#17">17</a>, <a href="sg3-closed.html#23">23</a>, <a href="sg3-closed.html#26">26</a>, <a href="sg3-closed.html#28">28</a>, <a href="sg3-closed.html#30">30</a>, <a href="sg3-closed.html#31">31</a>, <a href="sg3-closed.html#46">46</a>.</li>
<li>Added the following 2 Dup issues: <a href="sg3-closed.html#43">43</a>, <a href="sg3-closed.html#51">51</a>.</li>
<li>No issues changed.</li>
</ul></li>
</ul>
</li>
</ul>

<h2><a name="Status"></a>Issue Status</h2>

  <p>Issues reported to the SG transition through a variety of statuses,
  indicating their progress towards a resolution.  Typically, most issues
  will flow through the following stages.
  </p>

  <p><b><a name="New">New</a></b> - The issue has not yet been
  reviewed by the SG. Any <b>Proposed Resolution</b> is purely a
  suggestion from the issue submitter, and should not be construed as
  the view of SG.</p>

  <p><b><a name="Open">Open</a></b> - The SG has discussed the issue
  but is not yet ready to move the issue forward. There are several
  possible reasons for open status:</p>
     <ul>
        <li>Consensus may have not yet have been reached as to how to deal
            with the issue.</li>
        <li>Informal consensus may have been reached, but the SG awaits
            exact <b>Proposed Resolution</b> wording for review.</li>
        <li>The SG wishes to consult additional technical experts before
            proceeding.</li>
        <li>The issue may require further study.</li>
     </ul>

  <p>A <b>Proposed Resolution</b> for an open issue is still not be
  construed as the view of SG. Comments on the current state of
  discussions are often given at the end of open issues in an italic
  font. Such comments are for information only and should not be given
  undue importance.</p>

  <p><b><a name="Review">Review</a></b> - Exact wording of a
  <b>Proposed Resolution</b> is now available for review on an issue
  for which the SG previously reached informal consensus.</p>

  <p><b><a name="Ready">Ready</a></b> - The SG has reached consensus
  that the issue is a defect in the Standard, the <b>Proposed
  Resolution</b> is correct, and the issue is ready to forward to the
  full committee for further action as a Defect Report (DR).</p>

  <p>Typically, an issue must have a proposed resolution in the currently
  published issues list, whose wording does not change during SG review, to
  move to the Ready status.</p>

  <p><b><a name="Voting">Voting</a></b> - This status should not be seen
  in a published issues list, but is a marker for use during meetings to
  indicate an issues was Ready in the pre-meeting mailing, the <b>Proposed
  Resolution</b> is correct, and the issue will be offered to the working
  group at the end of the current meeting to apply to the current working
  paper (WP) or to close in some other appropriate manner.  This easily
  distinguishes such issues from those moving to Ready status during the
  meeting itself, that should not be forwarded until the next meeting.  If
  the issue does not move forward, it should fall back to one of the other
  open states before the next list is published.</p>

  <p><b><a name="Immediate">Immediate</a></b> - This status should not be
  seen in a published issues list, but is a marker for use during meetings
  to indicate an issues was not Ready in the pre-meeting mailing, but the
  <b>Proposed Resolution</b> is correct, and the issue will be offered to
  the working group at the end of the current meeting to apply to the
  current working paper (WP) or to close in some other appropriate manner.
  This status is used only rarely, typically for fixes that are both small
  and obvious, and usually within a meeting of the expected publication of
  a revised standard.  If the issue does not move forward, it should fall
  back to one of the other open states before the next list is published.</p>

  <p>In addition, there are a few ways to categorise and issue that remains
  open to a resolution within the library, but is not actively being worked
  on.
  </p>

  <p><b><a name="Deferred">Deferred</a></b> - The SG has discussed the issue,
  is not yet ready to move the issue forward, but neither does it deem the
  issue significant enough to delay publishing a standard or Technical Report.
  A typical deferred issue would be seeking to clarify wording that might be
  technically correct, but easily mis-read.</p>

  <p>A <b>Proposed Resolution</b> for a deferred issue is still not be
  construed as the view of SG. Comments on the current state of
  discussions are often given at the end of open issues in an italic
  font. Such comments are for information only and should not be given
  undue importance.</p>

  <p><b><a name="Core">Core</a></b> - The SG has discussed the issue, and feels
  that some key part of resolving the issue is better handled by a cleanup of
  the language in the Core part of the standard.  The issue is passed to the Core
  Working Group, which should ideally open a corresponding issue that can be
  linked from the library issue.  Such issues will be revisitted after Core have
  made (or declined to make) any changes.
  </p>

  <p><b><a name="EWG">EWG</a></b> - The SG has discussed the issue, and wonder
  that some key part of resolving the issue is better handled by some (hopefully
  small) extension to the language.  The issue is passed to the Evolution Working
  Group, which should ideally open a corresponding issue that can be linked from
  the library issue.  Such issues will be revisitted after Evoltion have made (or
  declined to make) any recommendations.  Positive recommendations from EWG will
  often mean the issue transition to <i>Core</i> status while we wait for some
  proposed new feature to land in the working paper.
  </p>

  <p>Ultimately, all issues should reach closure with one of the following statuses.
  </p>

  <p><b><a name="DR">DR</a></b> - (Defect Report) - The full WG21/PL22.16
  committee has voted to forward the issue to the Project Editor to be
  processed as a Potential Defect Report. The Project Editor reviews
  the issue, and then forwards it to the WG21 Convenor, who returns it
  to the full committee for final disposition. This issues list
  accords the status of DR to all these Defect Reports regardless of
  where they are in that process.</p>

  <p><b><a name="WP">WP</a></b> - (Working Paper) - The proposed resolution has not been
  accepted as a Technical Corrigendum, but the full WG21/PL22.16 committee has voted to
  apply the Defect Report's Proposed Resolution to the working paper.</p>

  <p><b><a name="C++11">C++11</a></b> - (C++ Standard, as revised for 2011) - The full
  WG21/PL22.16 committee has voted to accept the Defect Report's Proposed Resolution into
  the published 2011 revision to the C++ standard, ISO/IEC TS 18822.</p>

   <p><b><a name="CD1">CD1</a></b> - (Committee Draft 2008) - The full
  WG21/PL22.16 committee has voted to accept the Defect Report's Proposed
  Resolution into the Fall 2008 Committee Draft.</p>

  <p><b><a name="TC1">TC1</a></b> - (Technical Corrigenda 1) - The full
  WG21/PL22.16 committee has voted to accept the Defect Report's Proposed
  Resolution as a Technical Corrigenda.  Action on this issue is thus
  complete and no further action is possible under ISO rules.</p>

  <p><b><a name="TRDec">TRDec</a></b> - (Decimal TR defect) - The SG has voted to
  accept the Defect Report's Proposed Resolution into the Decimal TR.  Action on this
  issue is thus complete and no further action is expected.</p>

  <p><b><a name="Resolved">Resolved</a></b> - The SG has reached consensus
  that the issue is a defect in the Standard, but the resolution adopted to
  resolve the issue came via some other mechanism than this issue in the
  list - typically by applying a formal paper, occasionally as a side effect
  of consolidating several interacting issue resolutions into a single issue.</p>

  <p><b><a name="Dup">Dup</a></b> - The SG has reached consensus that
  the issue is a duplicate of another issue, and will not be further
  dealt with. A <b>Rationale</b> identifies the duplicated issue's
  issue number.</p>

  <p><b><a name="NAD">NAD</a></b> - The SG has reached consensus that
  the issue is not a defect in the Standard.</p>

  <p><b><a name="NAD Editorial">NAD Editorial</a></b> - The SG has reached consensus that
  the issue can either be handled editorially, or is handled by a paper (usually
  linked to in the rationale).</p>

  <p><b><a name="NAD Future">NAD Future</a></b> - In addition to the regular
  status, the SG believes that this issue should be revisited at the next
  revision of the standard.</p>

  <p><b><a name="NAD Concepts">NAD Concepts</a></b> - This status reflects an evolution
  of the language during the development of C++11, where a new feature entered the
  language, called <i>concepts</i>, that fundamentally changed the way templates would
  be specified and written.  While this language feature was removed towards the end of
  the C++11 project, there is a clear intent to revisit this part of the language design.
  During that development, a number of issues were opened against the updated library
  related to use of that feature, or requesting fixes that would require exliciit use of
  the concepts feature.  All such issues have been closed with this status, and may be
  revisitted should this or a similar language feature return for a future standard.</p>

  <p><b>Tentatively</b> - This is a <i>status qualifier</i>.  The issue has
  been reviewed online, or at an unofficial meeting, but not in an official meeting, and
  some support has been formed for the qualified status.  Tentatively qualified issues may
  be moved to the unqualified status and forwarded to full committee (if Ready) within the
  same meeting.  Unlike Ready issues, Tentatively Ready issues will be reviewed in
  subcommittee prior to forwarding to full committee.  When a status is qualified with
  Tentatively, the issue is still considered active.</p>

  <p><b>Pending</b> - This is a <i>status qualifier</i>.  When prepended to a status this
  indicates the issue has been processed by the committee, and a decision has been made to
  move the issue to the associated unqualified status.  However for logistical reasons the
  indicated outcome of the issue has not yet appeared in the latest working paper.</p>

  <p>Issues are always given the status of <a href="sg3-active.html#New">New</a> when
  they first appear on the issues list. They may progress to
  <a href="sg3-active.html#Open">Open</a> or <a href="sg3-active.html#Review">Review</a>
  while the SG is actively working on them. When the SG has reached consensus on
  the disposition of an issue, the status will then change to
  <a href="sg3-active.html#Dup">Dup</a>, <a href="sg3-active.html#NAD">NAD</a>, or
  <a href="sg3-active.html#Ready">Ready</a> as appropriate.  Once the full PL22.16 committee
  votes to forward Ready issues to the Project Editor, they are given the status of Defect
  Report ( <a href="sg3-active.html#DR">DR</a>). These in turn may become the basis for
  Technical Corrigenda (<a href="sg3-active.html#TC1">TC1</a>), or are closed without action
  other than a Record of Response (<a href="sg3-active.html#Resolved">Resolved</a> ).  The
  intent of this SG process is that only issues which are truly defects in the Standard move
  to the formal ISO DR status.
  </p>


<h2>Active Issues</h2>
<hr>
<h3><a name="4"></a>4. [PDTS] Need definition of dot and dot-dot</h3>
<p><b>Section:</b> X 4.14 [fs.def.parent] <b>Status:</b> <a href="sg3-active.html#Open">Open</a>
 <b>Submitter:</b> CH-3 <b>Opened:</b> 2014-01-20 <b>Last modified:</b> 2014-02-27</p>
<p><b>View all issues with</b> <a href="sg3-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>The concept of a parent directory for dot or dotdot exists, but the definition doesn't apply.</p>

<p>Suggested action:</p>

<p>Remove the paragraph. This concept does not apply to dot and dot-dot. Add a definition for dot and dot-dot.</p>

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

<p>Suggest it is editorial and should be passed to the project editor.</p>

  <p><i>[
    2014-02-11 Issaquah: Beman to provide wording for review next meeting. Also see related issue 5.
  ]</i></p>



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





<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="sg3-active.html#Open">Open</a>
 <b>Submitter:</b> CH-4 <b>Opened:</b> 2014-01-20 <b>Last modified:</b> 2014-02-16</p>
<p><b>View all issues with</b> <a href="sg3-status.html#Open">Open</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><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>[<i>Note:</i> The <i>root-directory</i> has no parent directory.<i>&mdash; end note</i>]</ins>
Specific filenames may have special meanings for a particular operating system.
</p></blockquote>
</li>
</ol>






<hr>
<h3><a name="11"></a>11. [PDTS] Lack of <tt>relative()</tt> operation function</h3>
<p><b>Section:</b> X 6 &amp; 15 <b>Status:</b> <a href="sg3-active.html#Open">Open</a>
 <b>Submitter:</b> GB-1 <b>Opened:</b> 2014-01-20 <b>Last modified:</b> 2014-02-16</p>
<p><b>View all issues with</b> <a href="sg3-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
There is no <tt>relative()</tt> operation, to complement both <tt>absolute()</tt> and <tt>canonical()</tt>
</p>
<p>
The TS introduces relative paths. 
</p>

<ul>
  <li>
    <p>
      They are defined in section 4.18
      relative path [fs.def.relative-path]
    </p> </li>
  <li>
    <p>
      A decomposition method

      <tt>relative_path()</tt>
      is described in section 8.4.9 path decomposition [path.decompose]
    </p> 
  </li>
  <li>
  <p>
  
  Two query methods to determine if a path 
  either <tt>has_relative_path()</tt> or 
  <tt>is_relative()</tt> described in 8.4.10 path query [path.query] </p>
</li>
</ul>
<p>
However there is no way to create a relative path as a path relative to another. 
Methods are provided to create absolute and canonical paths.
</p>
<p>

In section 15.1 Absolute [fs.op.absolute]:</p>
<p>

path absolute(const 
path&amp; 
p,
const 
path&amp; 
base=current_path());</p>
<p>

and in section 15.2 Canonical [fs.op.canonical]</p>
<p>

path canonical(const 
path&amp; 
p,
const 
path&amp; 
base = 
current_path());</p>
<p>

path canonical(const 
path&amp; 
p, 
error_code&amp; 
ec);</p>
<p>

path canonical(const 
path&amp; 
p,
const 
path&amp; 
base, 
error_code&amp; 
ec);</p>
<p>
By providing a 
operations to achieve absolute and canonical paths there is no impediment to 
providing a similar operation 

relative() 
that
attempts to return a new path relative to 
some base path.</p>
<p>

For example:</p>
<p>

path relative(const 
path&amp; 
p,
const 
path&amp; 
to = 
current_path());</p>
<p>

path relative(const 
path&amp; 
p, 
error_code&amp; 
ec);</p>
<p>

path relative(const 
path&amp; 
p,
const 
path&amp; 
to, 
error_code&amp; 
ec);</p>
<p>

This would return a 
path, if possible, that is relative to 

to. 
The implementation can make use of 

absolute() 
and 
canonical() 
to determine the relative path, if it exists.</p>
<p>

The File System TS is 
based on the 
<a href="http://www.boost.org/doc/libs/1_55_0/libs/filesystem/doc/index.htm">

<u>&#8203;</u></a><a href="http://www.boost.org/doc/libs/1_55_0/libs/filesystem/doc/index.htm">boost::filesystem 
library</a> and it too suffers from this anomaly. There are open tickets for 
this in 
<a href="https://svn.boost.org/">

<u>&#8203;</u></a><a href="https://svn.boost.org/">Boost 
Trac</a>:</p>
<ul>
  <li>
  <p>
  
  <a href="https://svn.boost.org/trac/boost/ticket/5897">
  <u>&#8203;</u></a><a href="https://svn.boost.org/trac/boost/ticket/5897">#5897 
  Make path relative function</a>
  </p>
</li>
  <li>
  <p>
  
  <a href="https://svn.boost.org/trac/boost/ticket/1976">
  <u>&#8203;</u></a><a href="https://svn.boost.org/trac/boost/ticket/1976">#1976 
  Inverse function for complete</a>
  </p>
</li>
</ul>
<p>

and it is the subject of several posts on StackOverflow for example:</p>
<ul>
  <li>
  <p>
  
  <a href="http://stackoverflow.com/questions/10167382/boostfilesystem-get-relative-path">
  <u>&#8203;</u></a><a href="http://stackoverflow.com/questions/10167382/boostfilesystem-get-relative-path">http://stackoverflow.com/questions/10167382/boostfilesystem-get-relative-path</a>
  </p>
</li>
  <li>
  <p>
  
  <a href="http://stackoverflow.com/questions/5772992/get-relative-path-from-two-absolute-paths">
  <u>&#8203;</u></a><a href="http://stackoverflow.com/questions/5772992/get-relative-path-from-two-absolute-paths">http://stackoverflow.com/questions/5772992/get-relative-path-from-two-absolute-paths</a>
  </p>
</li>
</ul>
<p>

Other languages typically provide a similar function. For example python 
provides:</p>
<p>

os.path.relpath(path[, 
start])</p>
<p>

Return a relative 
filepath to 
path 
either from the current directory or from an optional 

start 
directory. This is a path computation: the filesystem is not accessed to confirm 
the existence or nature of 
path 
or 
start.
start 
defaults to 
os.curdir.</p>

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


<p>A <code>relative()</code> function is useful and much requested.
I've seen such a function provided by users and have written it myself in app code.
It is one of those things I've been meaning to do for years, and have just never gotten around to.</p>

  <p>That said, my mild preference is to treat this as "NAD, Future" for File System TS1,
  but treat it as a priority for TS2.</p>

  <p><i>[
    2014-02-11 Issaquah
  ]</i></p>

<p>
 The LWG/SG-3 voted strongly in favor of adding this functionality, and doing so in
    this TS. That implies quite a bit of work before the next meeting to validate that the proposed interface
    works as desired for various platforms. There was general agreement not to hold FS STS1 if this functionality
    isn't ready when the rest of the TS is ready.
</p>




<p><b>Proposed resolution:</b></p>
<ol>
<li>
<p>Modify header <tt>&lt;filesystem&gt;</tt> synopsis, 6 [fs.filesystem.synopsis],
by adding the operational functions after <tt>canonical</tt>:</p>
<blockquote><pre>
path relative(const path&amp; p, const path&amp; to = current_path());
path relative(const path&amp; p, error_code&amp; ec);
path relative(const path&amp; p, const path&amp; to, error_code&amp; ec);
</pre></blockquote>
</li>
<li><p>Insert the section:</p>
<blockquote><p>
15.3 Relative [fs.op.relative]
</p>
<pre>
path relative(const path&amp; p, const path&amp; to = current_path());
path relative(const path&amp; p, error_code&amp; ec);
path relative(const path&amp; p, const path&amp; to, error_code&amp; ec);</pre>
<blockquote>
<p><i>Overview</i>: Return a relative path of p to the current directory or from an optional to path.</p>
<p><i>Returns</i>: A relative path such that <tt>canonical(to)/relative(p,to) == canonical(p)</tt>,
otherwise <tt>path()</tt>. If <tt>canonical(to) == canonical(p)</tt> the path <tt>path(".")</tt> is returned. For the
overload without a <tt>to</tt> argument, <tt>to</tt> is <tt>current_path()</tt>. Signatures with argument <tt>ec</tt> return
<tt>path()</tt> if an error occurs.
</p>
<p>
<i>Throws</i>: As specified in Error reporting.</p>
<p>
<i>Remarks</i>: <tt>!exists(p) or !exists(to) or !is_directory(to)</tt> is an error.
</p>
</blockquote></blockquote>
<p>
and bump all following sections up by 0.1. Update the contents and any cross-references
accordingly.
</p>
</li>
</ol>
<p>
Question: Should Returns be specified in terms of equivalence? For example:
<tt>equivalent( canonical(to)/relative(p,to), canonical(p) )</tt>
</p>
<p>
Question: Should <tt>canonical(to) == canonical(p)</tt> return <tt>path(".")</tt> or <tt>path()</tt>? Why?
</p>
<p>

Question: Should <tt>to</tt> be spelt start?</p>




<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="sg3-active.html#Open">Open</a>
 <b>Submitter:</b> CH-13 <b>Opened:</b> 2014-01-20 <b>Last modified:</b> 2014-02-16</p>
<p><b>View all issues with</b> <a href="sg3-status.html#Open">Open</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><b>Proposed resolution:</b></p>





<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="sg3-active.html#Open">Open</a>
 <b>Submitter:</b> CH-15 <b>Opened:</b> 2014-01-20 <b>Last modified:</b> 2014-02-16</p>
<p><b>View all issues with</b> <a href="sg3-status.html#Open">Open</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><b>Proposed resolution:</b></p>





<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="sg3-active.html#Review">Review</a>
 <b>Submitter:</b> FI-9 <b>Opened:</b> 2014-01-20 <b>Last modified:</b> 2014-02-28</p>
<p><b>View all issues with</b> <a href="sg3-status.html#Review">Review</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>Change 15.14 [fs.op.file_size]:</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>exists(p) &amp;&amp; is_regular_file(p)</code>, 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>. 
  Otherwise<del>, <code>static_cast&lt;uintmax_t&gt;(-1)</code></del> <ins>an error is reported (7)</ins>. 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="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="sg3-active.html#New">New</a>
 <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2014-01-30 <b>Last modified:</b> 2014-03-01</p>
<p><b>View other</b> <a href="sg3-index-open.html# [fs.filesystem.synopsis">active issues</a> in 6 [fs.filesystem.synopsis].</p>
<p><b>View all other</b> <a href="sg3-index.html# [fs.filesystem.synopsis">issues</a> in 6 [fs.filesystem.synopsis].</p>
<p><b>View all issues with</b> <a href="sg3-status.html#New">New</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></p>





<hr>
<h3><a name="35"></a>35. [PDTS] <tt>directory_options::skip_permissions_denied</tt> is not used</h3>
<p><b>Section:</b> X 6 [fs.filesystem.synopsis] <b>Status:</b> <a href="sg3-active.html#New">New</a>
 <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2014-01-30 <b>Last modified:</b> 2014-02-16</p>
<p><b>View other</b> <a href="sg3-index-open.html# [fs.filesystem.synopsis">active issues</a> in 6 [fs.filesystem.synopsis].</p>
<p><b>View all other</b> <a href="sg3-index.html# [fs.filesystem.synopsis">issues</a> in 6 [fs.filesystem.synopsis].</p>
<p><b>View all issues with</b> <a href="sg3-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<tt>directory_options::skip_permissions_denied</tt> is not used.
</p>


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





<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="sg3-active.html#New">New</a>
 <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2014-01-30 <b>Last modified:</b> 2014-02-16</p>
<p><b>View all other</b> <a href="sg3-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="sg3-status.html#New">New</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><b>Proposed resolution:</b></p>
<p></p>





<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="sg3-active.html#New">New</a>
 <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2014-01-30 <b>Last modified:</b> 2014-02-27</p>
<p><b>View all issues with</b> <a href="sg3-status.html#New">New</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 2360.
<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="sg3-active.html#37">37</a>,
<a href="sg3-active.html#38">38</a>,
<a href="sg3-active.html#41">41</a>,
and <a href="sg3-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><b>Proposed resolution:</b></p>
<p></p>





<hr>
<h3><a name="38"></a>38. [PDTS] Make certain functions <tt>noexcept</tt> and drop <tt>error_code</tt> version</h3>
<p><b>Section:</b> X 12.3 [directory_entry.obs], X 15.12 [fs.op.exists], X 15.16 [fs.op.is_block_file], X 15.17 [fs.op.is_char_file], X 15.18 [fs.op.is_directory], X 15.19 [fs.op.is_empty], X 15.20 [fs.op.is_fifo], X 15.21 [fs.op.is_other], X 15.22 [fs.op.is_regular_file], X 15.23 [fs.op.is_socket], X 15.24 [fs.op.is_symlink], X 15.33 [fs.op.status], X 15.35 [fs.op.symlink_status], X 15.38 [fs.op.unique_path] <b>Status:</b> <a href="sg3-active.html#New">New</a>
 <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2014-01-30 <b>Last modified:</b> 2014-02-27</p>
<p><b>View all other</b> <a href="sg3-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="sg3-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<tt>exists(const path&amp;)</tt> should be <tt>noexcept</tt> (drop <tt>error_code</tt> version).<br/>
<tt>is_*(const path&amp;)</tt> should be <tt>noexcept</tt> (drop <tt>error_code</tt> version).<br/>
<tt>status(const path&amp;)</tt> should be <tt>noexcept</tt> (drop <tt>error_code</tt> version).<br/>
<tt>symlink_status(const path&amp;)</tt> should be <tt>noexcept</tt> (drop <tt>error_code</tt> version).<br/>
<tt>file_status::status()</tt> should be <tt>noexcept</tt> (drop <tt>error_code</tt> version).<br/>
<tt>file_status::symlink_status()</tt> should be <tt>noexcept</tt> (drop <tt>error_code</tt> version).<br/>
<tt>unique_path(const path&amp;)</tt> should be <tt>noexcept</tt> (drop <tt>error_code</tt> version).
</p>

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

<p>
<tt>unique_path(const path&amp;)</tt> cannot be declared as <tt>noexcept</tt>, because it returns an object
during whose construction a memory allocation request may fail, see the rationale provided in <a href="sg3-active.html#37">37</a>.
<p/>
<tt>exists(const path&amp;)</tt> and the <tt>is_*(const path&amp;)</tt> functions cannot be <tt>noexcept</tt>, because 
they are specified in terms of <tt>status(const path&amp;)</tt>, which again may throw an exception, which is explicitly 
described in the Effects (<tt>filesystem_error</tt>), because the non-throwing function (<tt>status(const path&amp;, error_code&amp;)</tt>) 
may fail to satisfy the request.
<p/>
<tt>symlink_status(const path&amp;)</tt> may throw an exception for similar reasons that <tt>status(const path&amp;)</tt>
could fail.
<p/>
The reference to <tt>file_status::status()/symlink_status()</tt> looks like a typo to me (there are no such functions
in <tt>file_status</tt>), presumably <tt>directory_entry::status()/symlink_status()</tt> was meant. In this case I see 
no reason how these could be marked as <tt>noexcept</tt>, because these functions all may fail and may throw an exception.
<p/>
Based on this interpretation of the issue discussion I recommend to resolve this issue as NAD.
</p>

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


<p/>Issues <a href="sg3-active.html#37">37</a>,
<a href="sg3-active.html#38">38</a>,
<a href="sg3-active.html#41">41</a>,
and <a href="sg3-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><b>Proposed resolution:</b></p>
<p></p>





<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="sg3-active.html#New">New</a>
 <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2014-01-30 <b>Last modified:</b> 2014-02-16</p>
<p><b>View other</b> <a href="sg3-index-open.html#2 [class.directory_entry">active issues</a> in 12 [class.directory_entry].</p>
<p><b>View all other</b> <a href="sg3-index.html#2 [class.directory_entry">issues</a> in 12 [class.directory_entry].</p>
<p><b>View all issues with</b> <a href="sg3-status.html#New">New</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><b>Proposed resolution:</b></p>
<p></p>





<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="sg3-active.html#New">New</a>
 <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2014-01-30 <b>Last modified:</b> 2014-03-01</p>
<p><b>View all other</b> <a href="sg3-index.html#3 [class.directory_iterator">issues</a> in 13 [class.directory_iterator].</p>
<p><b>View all issues with</b> <a href="sg3-status.html#New">New</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="sg3-active.html#37">37</a>,
<a href="sg3-active.html#38">38</a>,
<a href="sg3-active.html#41">41</a>,
and <a href="sg3-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><b>Proposed resolution:</b></p>
<p></p>





<hr>
<h3><a name="42"></a>42. 
[PDTS] <tt>class path</tt> should have defaulted constructors/destructor/assignments.
</h3>
<p><b>Section:</b> X 8 [class.path] <b>Status:</b> <a href="sg3-active.html#New">New</a>
 <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2014-01-30 <b>Last modified:</b> 2014-02-26</p>
<p><b>View all other</b> <a href="sg3-index.html# [class.path">issues</a> in 8 [class.path].</p>
<p><b>View all issues with</b> <a href="sg3-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<tt>class path</tt> should have defaulted constructors/destructor/assignments.
</p>

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


<p/>Suggest NAD. Earlier versions did have defaulted constructors/destructor/assignments,
but they were removed at the request of Alberto Ganesh Barbati (c++std-filesys January 8, 2013):

<blockquote>
<p/>Speaking of <tt>=default</tt>, we have to be careful not over-constrain the specification.
I mean, if we just specify the intended meaning of those function with proper wording,
the implementation is allowed to use <tt>=default</tt> in case it provides an equivalent behaviour,
but if we put <tt>=default</tt> in the specification, the implementation is required to use it.
However, we have to remember that "for exposition only" data members may not be an
exhaustive list and that 17.5.2.3/2 allows implementations to provide an equivalent
behaviour using different members for which "default" construction/copy/assignment
may not be appropriate.

<p/><tt>=default</tt> is what we want for tuple, atomics, etc. It might be appropriate for
simple types like file_status, but, for more complex types like <tt>path</tt> itself,
I'd remove it and add proper wording.
</blockquote>  



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





<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="sg3-active.html#New">New</a>
 <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2014-01-30 <b>Last modified:</b> 2014-02-28</p>
<p><b>View all issues with</b> <a href="sg3-status.html#New">New</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>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="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="sg3-active.html#New">New</a>
 <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2014-01-30 <b>Last modified:</b> 2014-02-28</p>
<p><b>View all issues with</b> <a href="sg3-status.html#New">New</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><b>Proposed resolution:</b></p>
<p>In the entire Working Paper, change each instance of "<code>charT</code>" to "<code>C</code>".</p>
<p>For example, in 5 [fs.req]:</p>
<blockquote>Template parameters named <del><code>charT</code></del> <ins><code>C</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="sg3-active.html#New">New</a>
 <b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2014-02-03 <b>Last modified:</b> 2014-02-27</p>
<p><b>View all other</b> <a href="sg3-index.html#.4.1 [path.construct">issues</a> in 8.4.1 [path.construct].</p>
<p><b>View all issues with</b> <a href="sg3-status.html#New">New</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="sg3-active.html#37">37</a>,
<a href="sg3-active.html#38">38</a>,
<a href="sg3-active.html#41">41</a>,
and <a href="sg3-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><b>Proposed resolution:</b></p>





<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="sg3-active.html#Open">Open</a>
 <b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2014-02-03 <b>Last modified:</b> 2014-02-16</p>
<p><b>View other</b> <a href="sg3-index-open.html#2 [class.directory_entry">active issues</a> in 12 [class.directory_entry].</p>
<p><b>View all other</b> <a href="sg3-index.html#2 [class.directory_entry">issues</a> in 12 [class.directory_entry].</p>
<p><b>View all issues with</b> <a href="sg3-status.html#Open">Open</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><b>Proposed resolution:</b></p>
<p></p>





<hr>
<h3><a name="54"></a>54. [PDTS] Concerns with security and testability</h3>
<p><b>Section:</b> X all <b>Status:</b> <a href="sg3-active.html#New">New</a>
 <b>Submitter:</b> Google <b>Opened:</b> 2014-01-20 <b>Last modified:</b> 2014-02-28</p>
<p><b>View all issues with</b> <a href="sg3-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
  <p>We have two primary concerns with the interface as specified: </p>
  <p>
    (a) its interface repeats the mistake of V7 Unix in 1979 by exposing access
    checking (and similarly file creation) independently from opening and mutating
    the file, and
  </p>
  <p>
    (b) it provides no realistic means of testing a software library which uses
    the standard interface for accessing the filesystem under fault scenarios.
  </p>
  <p>
    Due to the extent of (a), TOCTTOU [1] security vulnerabilities are
    guaranteed, if not during access checking[2], during other common operations
    such as temporary file creation[3].
  </p>
  <p>
    Due to (b) it is impossible to portably test libraries using the proposed
    interface against critical correctness and security edge cases.
  </p>
  <p>
    [1]: TOCTTOU: Time-of-check-to-time-of-use.&nbsp;
    <a HREF="http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=5388162">Operating system integrity in OS/VS2</a>
  </p>
      <p>[2]: <a HREF="http://www.csl.sri.com/users/ddean/papers/usenix04.pdf">Fixing Races for Fun and Profit: How to use access(2)</a></p>
      <p>[3]: <a HREF="http://www.cs.ucdavis.edu/research/tech-reports/1995/CSE-95-10.pdf">Checking for Race Conditions in File Accesses</a></p>

  <p/>
  
  <i>[Beman Dawes: 10 Feb 2014: Suggested response: NAD, Future]</i>

  <blockquote>
    <p/>We share your concerns and look forward to receiving specific proposals to address them.
    Whether they will addressed by a revision of TS 18822 or a new TS will be decided as proposals progress
    through the committee process. See <a href="http://isocpp.org/std/submit-a-proposal">How To Submit a Proposal</a>.
  </blockquote>

    

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





<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="sg3-active.html#New">New</a>
 <b>Submitter:</b> Clark Nelson <b>Opened:</b> 2014-02-10 <b>Last modified:</b> 2014-02-28</p>
<p><b>View all issues with</b> <a href="sg3-status.html#New">New</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>These macros allow users to determine which versions of this Technical Specification
   are 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 definitions:</ins></p>
  <blockquote>
    <pre><ins>#define __cpp_lib_experimental_filesystem     201406</ins>
<ins>#define __cpp_lib_experimental_filesystem_v1  201406</ins></pre>
  </blockquote>
<p><ins>[<i>Note:</i> These macros follow  WG21 SD-6, Feature-testing 
recommendations for C++.</ins></p>
<p><ins>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.</ins></p>

<p><ins>A macro in the form <code>
__cpp_lib_experimental_filesystem_v</code><i>n</i> is provided for each inner 
namespace <code>v</code><i>n</i> supplied by the implementation. The value of each macro
<code>__cpp_lib_experimental_filesystem_v</code><i>n</i> is the same as the value of macro
<code>__cpp_lib_experimental_filesystem</code> for the corresponding version of the Technical
Specification. <i>— 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="sg3-active.html#Review">Review</a>
 <b>Submitter:</b> LWG/SG-3 <b>Opened:</b> 2014-02-13 <b>Last modified:</b> 2014-02-28</p>
<p><b>View all other</b> <a href="sg3-index.html#.1 [fs.conform.9945">issues</a> in 2.1 [fs.conform.9945].</p>
<p><b>View all issues with</b> <a href="sg3-status.html#Review">Review</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="sg3-active.html#New">New</a>
 <b>Submitter:</b> LWG/SG-3 <b>Opened:</b> 2014-02-13 <b>Last modified:</b> 2014-02-26</p>
<p><b>View all other</b> <a href="sg3-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="sg3-status.html#New">New</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><b>Proposed resolution:</b></p>
<p>Rewrite the <tt>last_write_time</tt> setter description to utilize <tt>utimensat() or similar.</tt></p>





<hr>
<h3><a name="59"></a>59. [PDTS] Invalid expressions for bitmask types</h3>
<p><b>Section:</b> X 10 [fs.enum] <b>Status:</b> <a href="sg3-active.html#New">New</a>
 <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2014-03-01 <b>Last modified:</b> 2014-03-01</p>
<p><b>View all issues with</b> <a href="sg3-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p/><code>copy_options</code> is declared as <code>enum class</code> type that is a bismask type, but the 
specification repeatedly uses expressions that are invalid for scoped 
enums, such as:

<blockquote>

<p/><code>!(options)</code>

</blockquote>

<p/>because there is no contextual conversion to bool, not even the || operator in:

<blockquote>
<p/><code>((options &amp; copy_options::recursive) || !(options)) </code>
</blockquote>

<p/>Affected are basically all formulations in the form:

<blockquote>

<p/>&quot;if <code>options &amp; copy_options::create_symlinks</code> [..]&quot;

</blockquote>

<p/>because all rely on contextual conversion to bool. The only other specifically 
mention scoped enumeration in the standard that is also a bit mask type is the 
<code>launch</code> enum and 
the wording there always uses forms such as:

<blockquote>

<p/>&quot;if <code>policy &amp; launch::deferred</code> is non-zero&quot;

</blockquote>

<p/>which better acknowledges the fact that the obtained values does not necessarily 
undergo an implicit conversion.

<p/>I think the current wording in the file system spec. must be changed, especially for 
invalid expressions of the form:

<blockquote>

<p/><code>((options &amp; copy_options::recursive) || !(options)) </code>
</blockquote>

<p/>A similar problem arises in the usage of the bitmask type <code>perms</code> for the 
expression:

<blockquote>

<p/><code>((prms &amp; add_perms) &amp;&amp; (prms &amp; remove_perms)) </code>
</blockquote>

<p/>The only way how to describe this with a scoped enum is the lengthier form

<blockquote>

<p/><code>((prms &amp; perms::add_perms) != perms::none &amp;&amp; (prms &amp; perms::remove_perms) != 
perms::none) </code>
</blockquote>

<p/>thus fixing several problems:

<ul>
  <li>The unscoped access to <code>add_perms</code> and <code>remove_perms</code> is incorrect</li>
  <li>The result of &amp; is the bitmask type again and cannot be implicitly 
  converted to bool</li>
</ul>




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





<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="sg3-active.html#New">New</a>
 <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2014-02-28 <b>Last modified:</b> 2014-03-02</p>
<p><b>View all issues with</b> <a href="sg3-status.html#New">New</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>
  





</body>
</html>
