Doc. no. | N4211 |
Date: | 2014-10-11 |
Project: | Programming Language C++ |
Reply to: | Beman Dawes <bdawes at acm dot org> |
Revised 2014-10-11 at 18:10:45 UTC
Reference ISO/IEC TS 18822
Also see:
The purpose of this document is to record the status of issues which have come before the File System Study Group (SG3) of the INCITS PL22.16 and ISO WG21 C++ Standards Committee. Issues represent potential defects in the ISO/IEC TS 18822 document.
This document contains only study group issues which are actively being
considered by the Study Group, i.e., issues which have a
status of New, Open,
Ready, or Review. See
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 Issue Status.
This document includes [bracketed italicized notes] as a reminder to the SG3 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 SG3 support for a particular resolution can quickly change if new viewpoints or killer examples are presented in subsequent discussions.
For the most current official version of this document see http://www.open-std.org/jtc1/sc22/wg21/. 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.
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.
Issues reported to the SG3 transition through a variety of statuses, indicating their progress towards a resolution. Typically, most issues will flow through the following stages.
New - The issue has not yet been reviewed by the SG3. Any Proposed Resolution is purely a suggestion from the issue submitter, and should not be construed as the view of SG3.
Open - The SG3 has discussed the issue but is not yet ready to move the issue forward. There are several possible reasons for open status:
A Proposed Resolution for an open issue is still not be construed as the view of SG3. 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.
Review - Exact wording of a Proposed Resolution is now available for review on an issue for which the SG3 previously reached informal consensus.
Ready - The SG3 has reached consensus that the issue is a defect in the Standard, the Proposed Resolution is correct, and the issue is ready to forward to the full committee for further action as a Defect Report (DR).
Typically, an issue must have a proposed resolution in the currently published issues list, whose wording does not change during SG3 review, to move to the Ready status.
Voting - 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 Proposed Resolution 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.
Immediate - 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 Proposed Resolution 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.
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.
Deferred - The SG3 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.
A Proposed Resolution for a deferred issue is still not be construed as the view of SG3. 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.
Core - The SG3 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.
EWG - The SG3 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 Core status while we wait for some proposed new feature to land in the working paper.
Ultimately, all issues should reach closure with one of the following statuses.
DR - (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.
WP - (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.
C++11 - (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.
CD1 - (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.
TC1 - (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.
TRDec - (Decimal TR defect) - The SG3 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.
Resolved - The SG3 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.
Dup - The SG3 has reached consensus that the issue is a duplicate of another issue, and will not be further dealt with. A Rationale identifies the duplicated issue's issue number.
NAD - The SG3 has reached consensus that the issue is not a defect in the Standard.
NAD Editorial - The SG3 has reached consensus that the issue can either be handled editorially, or is handled by a paper (usually linked to in the rationale).
NAD Future - In addition to the regular status, the SG3 believes that this issue should be revisited at the next revision of the standard.
NAD Concepts - This status reflects an evolution of the language during the development of C++11, where a new feature entered the language, called concepts, 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.
Tentatively - This is a status qualifier. 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.
Pending - This is a status qualifier. 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.
Issues are always given the status of New when they first appear on the issues list. They may progress to Open or Review while the SG3 is actively working on them. When the SG3 has reached consensus on the disposition of an issue, the status will then change to Dup, NAD, or Ready 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 ( DR). These in turn may become the basis for Technical Corrigenda (TC1), or are closed without action other than a Record of Response (Resolved ). The intent of this SG3 process is that only issues which are truly defects in the Standard move to the formal ISO DR status.
directory_entry
Section: X [fs.op.file_size] Status: New Submitter: Gor Nishanov Opened: 2014-05-22 Last modified: 2014-07-05
View all issues with New status.
Discussion:
On Windows, the FindFileData
structure, which is the underlying data type for directory_entry
, contains the file size as one of the fields.
Thus efficient enumeration of files and getting their sizes is possible without doing a separate query for the file size.
[17 Jun 2014 Rapperswil LWG will investigate issue at a subsequent meeting.]
Proposed resolution:
In section 12 Class directory_entry
[class.directory_entry] add the
following observer declarations:
uintmax_t file_size(); uintmax_t file_size(error_code& ec) noexcept;
In section 12.3 directory_entry
observers [directory_entry.obs]
add the following:
uintmax_t file_size(); uintmax_t file_size(error_code& ec) noexcept;Returns: if
*this
contains a cached file size, return it. Otherwise returnfile_size(path())
orfile_size(path(), ec)
respectively.Throws: As specified in Error reporting (7).
operator /
(and other append) semantics not useful if argument has rootSection: X 8.4.3 [8.4.3], 8.6 [path.non-member] Status: New Submitter: Peter Dimov Opened: 2014-05-30 Last modified: 2014-07-05
View all issues with New status.
Discussion:
In a recent discussion on the Boost developers mailing list, the semantics of operator /
and other append operations were questioned:
p1 / p2
is required to concatenate the
lexical representation of p1
and p2
, inserting a
preferred separator as needed.
This means that, for example, "c:\x" / "d:\y"
gives
"c:\x\d:\y"
, and that "c:\x" / "\\server\share"
gives "c:\x\\server\share"
. This is rarely, if ever, useful.
An alternative interpretation of p1 / p2
could be that it yields a
path that is the approximation of what p2
would mean if interpreted
in an environment in which p1
is the starting directory.
Under this interpretation, "c:\x" / "d:\y"
gives "d:\y"
,
which is more likely to match what was intended.
I am not saying that this second interpretation is the right one, but I do say
that we have reasons to suspect that the first one (lexical concatenation using
a separator) may not be entirely correct.
This leads me to think that the behavior of p1 / p2
, when p2
has a root, needs to be left implementation-defined, so that implementations are
not required to do the wrong thing, as above.
This change will not affect the ordinary use case in which p2
is a
relative, root-less, path.
[17 Jun 2014 Rapperswil LWG will investigate issue at a subsequent meeting.]
Proposed resolution:
remove_filename()
post condition is incorrectSection: X 4.8.5 [path.modifiers.remove_filename] Status: New Submitter: Eric Fiselier Opened: 2014-06-07 Last modified: 2014-07-05
View all issues with New status.
Discussion:
remove_filename()
specifies !has_filename()
as the post condition.
This post condition is not correct. For example the path "/foo"
has a filename of "foo"
. If we remove the filename we get "/"
,
and "/"
has a filename of "/"
.
[2014-06-08 Beman supplies an Effects: element.]
[17 Jun 2014 Rapperswil LWG will investigate issue at a subsequent meeting.]
Proposed resolution:
path& remove_filename();
Effects:
Postcondition:!has_filename()
.*this = parent_path()
, except that ifparent_path() == root_path()
,clear()
.Returns:
*this
.[Example:
std::cout << path("/foo").remove_filename();
// outputs "/
" std::cout << path("/").remove_
filename(); // outputs ""—end example]
Section: X throughout Status: New Submitter: Jonathan Wakely Opened: 2014-06-30 Last modified: 2014-07-05
View all issues with New status.
Discussion:
C++14 17.5.2.1.3 Bitmask types [bitmask.types] paragraph 4 specifies:
The following terms apply to objects and values of bitmask types:The TS should use these forms where applicable throughout the document.
- To set a value Y in an object X is to evaluate the expression X |= Y.
- To clear a value Y in an object X is to evaluate the expression X &= Y.
- The value Y is set in the object X if the expression X & Y is nonzero.
Proposed resolution:
path::root_directory()
description is confusingSection: X 8.4.9 [path.decompose] Status: New Submitter: Jonathan Wakely Opened: 2014-07-03 Last modified: 2014-07-04
View all issues with New status.
Discussion:
8.4.9 [path.decompose] p5 says:
If root-directory is composed of slash name, slash is excluded from the returned string.
but the grammar says that root-directory is just slash so that makes no sense.
Proposed resolution:
Change 8.4.9 [path.decompose] as indicated:
path root_directory() const;Returns: root-directory, if
pathname
includes root-directory, otherwisepath()
.
If root-directory is composed of slash name, slash is excluded from the returned string.
path::operator+=
is defined, but not operator+
Section: X 8 [class.path] Status: New Submitter: Jonathan Wakely Opened: 2014-07-03 Last modified: 2014-07-04
View all other issues in 8 [class.path].
View all issues with New status.
Discussion:
This doesn't seem to be in Boost.Filesystem, so maybe it isn't needed,
but since path += path2
works then it seems reasonable to expect
path1 + path2
to work as well.
[04 Jul 2014 Beman Dawes comments:]
The 12 overloads required by
basic_string operator+
scared me off, and I never came back to the issue.
Proposed resolution:
recursive_directory_iterator
effects refers to non-existent functions
Section: X 14.1 [rec.dir.itr.members] ¶39 Status: New Submitter: Jonathan Wakely Opened: 2014-07-10 Last modified: 2014-10-08
View all issues with New status.
Discussion:
operator++/increment
, second bullet item, says
"Otherwise if
recursion_pending() && is_directory(this->status())
&& (!is_symlink(this->symlink_status())
..."
but recursive_directory_iterator
does not have status
or symlink_status
members.
Proposed resolution:
Change 14.1 [rec.dir.itr.members] ¶39 as indicated:
Otherwise if
recursion_pending() && is_directory((*this)->status()) && (!is_symlink((*this)->symlink_status())
..."
system_complete
refers to undefined variable 'base'
Section: X 15.36 [fs.op.system_complete] Status: New Submitter: Jonathan Wakely Opened: 2014-07-20 Last modified: 2014-10-08
View all other issues in 15.36 [fs.op.system_complete].
View all issues with New status.
Discussion:
The example says "...or p
and base
have the same root_name()
.", but
base
is not defined. I believe it refers to the value returned by current_path()
.
Proposed resolution:
Change 15.36 [fs.op.system_complete] as indicated:
For Windows based operating systems,
system_complete(p)
has the same semantics asabsolute(p, current_path())
ifp.is_absolute() || !p.has_root_name()
orp
andhave the same
basecurrent_path()root_name()
. Otherwise it acts likeabsolute(p, cwd)
is the current directory for thep.root_name()
drive. This will be the current directory for that drive the last time it was set, and thus may be residue left over from a prior program run by the command processor. Although these semantics are useful, they may be surprising.
Section: X 15.3 [fs.op.copy] Status: New Submitter: Jonathan Wakely Opened: 2014-07-28 Last modified: 2014-10-08
View all other issues in 15.3 [fs.op.copy].
View all issues with New status.
Discussion:
15.3 [fs.op.copy] paragraph 16 says:
Otherwise if
!exists(t) & (options & copy_options::copy_symlinks) != copy_options::none
, thencopy_symlink(from, to, options)
.
But there is no overload of copy_symlink
that takes a copy_options
;
it should be copy_symlink(from, to)
.
15.3 [fs.op.copy] Paragraph 26 says:
as if by
for (directory_entry& x : directory_iterator(from))
but the result of dereferencing a directory_iterator
is const; it should be:
as if by
for (const directory_entry& x : directory_iterator(from))
Proposed resolution:
Change 15.3 [fs.op.copy] paragraph 16 as indicated:
Otherwise if
!exists(t) & (options & copy_options::copy_symlinks) != copy_options::none
, thencopy_symlink(from, to
., options)
Change 15.3 [fs.op.copy] paragraph 26 as indicated:
as if by
for (const directory_entry& x : directory_iterator(from))
Section: X 15.19 [fs.op.is_empty] Status: New Submitter: Jonathan Wakely Opened: 2014-08-01 Last modified: 2014-10-09
View all issues with New status.
Discussion:
The descriptions of most functions are explicit about the use of the ec
argument,
either saying something like "foo(p)
or foo(p, ec)
, respectively" or using the
ec
argument like foo(p[, ec])
, but is_empty
does not.
[fs.op.is_empty]/2 refers to ec
unconditionally, but more importantly
[fs.op.is_empty]/3 doesn't pass ec
to the directory_iterator
constructor or the file_size
function.
[ 9 Oct 2014 Beman supplies proposed wording. ]
Proposed resolution:
bool is_empty(const path& p); bool is_empty(const path& p, error_code& ec) noexcept;
Effects:
- Determine
file_status s
, as if bystatus(p)
orstatus(p, ec)
, respectively.- For the signature with argument
ec
, returnfalse
if an error occurred.- Otherwise, if
is_directory(s)
:
- Create
directory_iterator itr
, as if bydirectory_iterator(p)
ordirectory_iterator(p, ec)
, respectively.- For the signature with argument
ec
, returnfalse
if an error occurred.- Otherwise, return
itr == directory_iterator()
.- Otherwise:
- Determine
uintmax_t sz
, as if byfile_size(p)
orfile_size(p, ec)
, respectively .- For the signature with argument
ec
, returnfalse
if an error occurred.- Otherwise, return
sz == 0
.Remarks: The temporary objects described in Effects are for exposition only. Implementations are not required to create them.
Returns:
See Effects.is_directory(s) ? directory_iterator(p) == directory_iterator() : file_size(p) == 0;
The signature with argumentec
returnsfalse
if an error occurs.Throws: As specified in Error reporting (7).