Doc. no. | N4005
Date: | 2014-05-24
Project: | Programming Language C++
Reply to: | Beman Dawes <bdawes at acm dot org>

# File System TS Defect Report List (Revision R1)

Revised 2014-05-24 at 12:05:47 UTC

Reference ISO/IEC TS 18822

Also see:

- Table of Contents for all SG3 issues.
- Index by Section for all SG3 issues.
- Index by Status for all SG3 issues.
- Active Issues List
- Closed Issues List

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 DR, TC1, C++11, or Resolved. See the Closed Issues List for issues closed as non-defects. See the Active Issues List for active issues and more information. The introductory material in that document also applies to this document.

## Revision History

- R1: 2014-05-23 SG-3 File System TS
  - Summary:
    - 27 open issues, up by 27.
    - 35 closed issues, up by 35.
    - 62 issues total, up by 62.
  - Details:
    - Added the following 3 Review issues: 25, 27, 57.
    - Added the following 19 New issues: 34, 35, 36, 37, 38, 40, 41, 42, 45, 48, 49, 54, 56, 58, 59, 60, 61, 62, 63.
    - Added the following 5 Open issues: 4, 5, 11, 22, 53.
    - Added the following NAD Future issue: 12.
    - Added the following 22 WP issues: 1, 2, 3, 6, 7, 8, 9, 14, 15, 16, 18, 19, 21, 24, 29, 32, 33, 44, 47, 50, 52, 55.
    - Added the following NAD Editorial issue: 39.
    - Added the following 9 NAD issues: 10, 13, 17, 23, 26, 28, 30, 31, 46.
    - Added the following 2 Dup issues: 43, 51.
    - No issues changed.

## Defect Reports

### 1. [PDTS] Make namespaces consistent with Library TS policy

Section: X All Status: WP Submitter: FI-5, US-5, GB-3, CH-6 Opened: 2014-01-20 Last modified: 2014-04-18

View all issues with WP status.

Discussion:

The PDTS used a placeholder namespace "tbs" since the Standard Library policy for TS namespaces had not yet been fully articulated.

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

Proposed resolution:

[2014-02-07: Beman Dawes]

Throughout the WP, change namespace "tbs" to "experimental" as described in the Library Fundamentals TS working paper, 1.3 Namespaces and headers [general.namespaces].

### 2. [PDTS] Tighten specification when there is no reasonable behavior

Section: X 2.1 [fs.conform.9945] Status: WP Submitter: FI-1 Opened: 2014-01-20 Last modified: 2014-04-18

View all other issues in 2.1 [fs.conform.9945].

View all issues with WP status.

Discussion:

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.

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.

[2014-02-07, Beman Dawes suggests wording]

[2014-02-12, Daniel Krügler comments:]

> 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 `owner_exec` 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& 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".

[2014-02-12, Proposed wording updated to reflect LWG/SG-3 discussion in Issaquah.

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. ]

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

Proposed resolution:

1. Change 2.1:

   > If an implementation cannot provide any reasonable behavior, the implementation shall report an error in an implementation-defined manner as specified in § 7 [fs.err.report]. [Note: This allows users to rely on an exception being thrown or an error code being set when an implementation cannot provide any reasonable behavior. — end note] .

### 3. [PDTS] Filename length needs bullet item

Section: X 4.7 [fs.def.filename] Status: WP Submitter: CH-2 Opened: 2014-01-20 Last modified: 2014-04-18

View all issues with WP status.

Discussion:

Filename lengths are also implementation dependent. This is not the same as `FILENAME_MAX` that specifies the maximum length of pathnames.

Add a bullet: "Length of filenames."

[2014-02-07, Beman Dawes provides wording]

Proposed resolution:

Change 4.7 [fs.def.filename]:

The name of a file. Filenames dot and dot-dot have special meaning. The following characteristics of filenames are operating system dependent:

- The permitted characters. [Example: Some operating systems prohibit the ASCII control characters (0x00-0x1F) in filenames. — end example].

- The maximum permitted length.

- Filenames that are not permitted.

- Filenames that have special meaning.

- Case awareness and sensitivity during path resolution.

- Special rules that may apply to file types other than regular files, such as directories.

### 6. [PDTS] Path depth is underspecified

Section: X 4.15 [fs.def.path] Status: WP Submitter: CH-5 Opened: 2014-01-20 Last modified: 2014-04-08

View all issues with WP status.

Discussion:

Path depth is implementation dependent.

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

[2014-02-07, Beman Dawes comments]

"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.

[2014-02-07, Beman Dawes provides wording]

Proposed resolution:

Change 4.15 [fs.def.path]:

> 4.15 path [fs.def.path]

> A sequence of elements that identify the location of a file within a filesystem. The elements are the root-nameopt , root-directoryopt , and an optional sequence of filenames.

> The maximum number of elements in the sequence is operating system dependent.

### 7. [PDTS] Unhelpful comment for `struct space_info`

Section: X 6 [fs.filesystem.synopsis], 15.32 [fs.op.space] Status: WP Submitter: GB-4 Opened: 2014-01-20 Last modified: 2014-04-08

View all issues with WP status.

Discussion:

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)

Remove the comment and add a note to 15.32 [fs.op.space]: [Note: the precise meaning of available space is implementation dependent. — end note]

[2014-02-07, Beman Dawes comments]

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

[2014-02-07, Beman Dawes provides wording]

Proposed resolution:

1. Change 6 [fs.filesystem.synopsis]:

   > `uintmax_t available; // free space available to a non-privileged process`

2. Add Remarks to 15.32 [fs.op.space]:

   > Remarks: The value of member `space_info::available` is operating system dependent. [Note: `available` may be less than `free`. — end note]

### 8. [PDTS] `file_time_type` underspecified

Section: X [fs.filesystem.synopsis] Status: WP Submitter: CH-7 Opened: 2014-01-20 Last modified: 2014-04-18

View all issues with WP status.

Discussion:

Must the `file_time_type` hold times before 1960 and after 2050?

Specify the requirements to unspecified-trivial-clock for `file_time_type`.

[2014-02-10, Daniel suggests wording]

[ 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. ]

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

Proposed resolution:

1. Modify 6 [fs.filesystem.synopsis] as indicated:

   >         typedef chrono::time_point<unspecified-trivial-clock>  file_time_type;

   > unspecified-trivial-clock is an unspecified type provided by the implementation implementation-defined type that satisfies the TrivialClock requirements (C++11 ISO 14882:2011 §20.12.3) and that is capable of representing and measuring file time values. Implementations should ensure that the resolution and range of `file_time_type` reflect the operating system dependent resolution and range of file time values.

### 9. [PDTS] Unclear why range-based-for functions return different types

Section: X 6 [fs.filesystem.synopsis] Status: WP Submitter: FI-2 Opened: 2014-01-20 Last modified: 2014-04-08

View other active issues in 6 [fs.filesystem.synopsis].

View all other issues in 6 [fs.filesystem.synopsis].

View all issues with WP status.

Discussion:

It is unclear why the range-for support functions (begin()/end()) for `directory_iterator` and `recursive_directory_iterator` return different types for `begin()` and `end()`, namely that `begin()` returns a reference to `const` and `end()` returns a value.

[2014-02-07: Beman Dawes provides comments from the Boost implementation:]

      //  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.

[2014-02-08: Daniel responds to Beman]

The difference in return types becomes relevant, when testing whether e.g. `directory_iterator` would satisfy the `Traversable` requirements as currently specified in N3763. Expressed in code form these requirements impose that the following assertion holds:

>       static_assert(std::is_same<
>           decltype(std::range_begin(std::declval<directory_iterator>())),
>           decltype(std::range_end(std::declval<directory_iterator>()))
>         >::value, "No Traversable type");

Both `directory_iterator` and `recursive_directory_iterator` won't satisfy this requirement currently.

[ 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. ]

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

Proposed resolution:

1. Change 6 [fs.filesystem.synopsis]:

         class directory_iterator;

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

         class recursive_directory_iterator;

         // enable recursive_directory_iterator range-based for statements
         const recursive_directory_iterator& begin(const recursive_directory_iterator& iter) noexcept;
         recursive_directory_iterator end(const recursive_directory_iterator&) noexcept;

2. Change 13.2 [directory_iterator.nonmembers]:

   These functions enable use of `directory_iterator` with C++11 range-based for statements.

       const directory_iterator& begin(constdirectory_iterator& iter) noexcept;

   > Returns: `iter`.

       directory_iterator end(const directory_iterator&) noexcept;

   > Returns: `directory_iterator()`.

3. Change 14.2 [rec.dir.itr.nonmembers]:

   These functions enable use of `recursive_directory_iterator` with C++11 range-based for statements.

       const recursive_directory_iterator& begin(constrecursive_directory_iterator& iter) noexcept;

   > Returns: `iter`.

       recursive_directory_iterator end(const recursive_directory_iterator&) noexcept;

   > Returns: `recursive_directory_iterator()`.

### 14. [PDTS] Incorrect postconditions for `path` copy/move constructor

Section: X 8.4.1 [path.construct] Status: WP Submitter: GB-7, CH-10 Opened: 2014-01-20 Last modified: 2014-04-08

View all other issues in 8.4.1 [path.construct].

View all issues with WP status.

Discussion:

The postconditions for the copy/move constructor for path are shown as "empty()". This appears to have been incorrectly copied from the default ctor.

Remove the 'postconditions' clause from the copy/move ctor.

[2014-02-07, Beman Dawes suggests wording]

Proposed resolution:

Change 8.4.1 [path.construct]:

>           path(const path& p);
>           path(path&& p) noexcept;

> > Effects: Constructs an object of class `path` with `pathname` having the original value of `p.pathname`. In the second form, `p` is left in a valid but unspecified state.

> > Postconditions: empty().

### 15. [PDTS] Missing behavior for characters with no representation

Section: X 8.2.2 [path.type.cvt], X 8.4.1 [path.construct] Status: WP Submitter: GB-8 Opened: 2014-01-20 Last modified: 2014-04-18

View all issues with WP status.

Discussion:

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?

Suggested action:

Add some definition of the behaviour for characters with no representation.

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

[2014-02-08, Beman Dawes provides wording]

Proposed resolution:

Add a paragraph at the end of 8.2.2 [path.type.cvt]:

> If the encoding being converted to has no representation for source characters, the resulting converted characters, if any, are unspecified.

### 16. [PDTS] Append behavior underspecified if target is empty

Section: X 8.4.3 [path.append] Status: WP Submitter: CH-11 Opened: 2014-01-20 Last modified: 2014-04-18

View all issues with WP status.

Discussion:

Is the added separator redundant in p1 /= p2, where p1 is empty? I.e. does the result start with a separator?

Suggested action:

Specify what behaviour is required.

[2014-02-07: Beman Dawes comments]

The second bullet item is supposed to deal with the `empty()` condition.

[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.]

Proposed resolution:

Change 8.4.3 [path.append]:

> Effects:

> > Appends `path::preferred_separator` to `pathname` unless:

> > - an added separator would be redundant, or

> > - would change an relative path to an absolute path [Note: An empty path is relative. — end note], or

> > - `p.empty()`, or

> > - `*p.native().cbegin()` is a directory separator.

> > Then appends `p.native()` to `pathname`.

### 18. [PDTS] `is_absolute()` return clause confusing

Section: X 8.4.10 [path.query] Status: WP Submitter: FI-7 Opened: 2014-01-20 Last modified: 2014-04-08

View all issues with WP status.

Discussion:

`is_absolute` says: "Returns: true if the elements of `root_path()` uniquely identify a file system location, else false." The "uniquely identify a location" seems confusing in presence of symlinks.

Suggested action:

Clarify the returns clause so that there's no confusion about symlinks and 'location'.

[2014-02-10 Beman Dawes provides wording]

Proposed resolution:

Change 8.4.10 path query [path.query]:

>     bool is_absolute() const;

> > Returns: `true` if the elements of `root_path()` uniquely identify a file system location `pathname` contains an absolute path (4.1 [fs.def.absolute-path]) , else `false`.

> > [Example: `path("/").is_absolute()` is `true` for POSIX based operating systems, and `false` for Windows based operating systems. — end example]

### 19. [PDTS] Consider using quoted manipulators

Section: X 8.6.1 [path.io] Status: WP Submitter: FI-8 Opened: 2014-01-20 Last modified: 2014-04-18

View all issues with WP status.

Discussion:

"[Note: Pathnames containing spaces require special handling by the user to avoid truncation when read by the extractor. — end note]" sounds like a quoted manipulator as specified in the C++14 draft in [quoted.manip] would be useful.

Consider using quoted manipulators for stream insertion and extraction.

[2014-02-10, Daniel suggests wording]

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

Proposed resolution:

1. Change 8.6.1 [path.io] as indicated:

   >     template <class charT, class traits>
   >     basic_ostream<charT, traits>&
   >     operator<<(basic_ostream<charT, traits>& os, const path& p);

   > > Effects: `os << quoted(p.string<charT, traits>())`.

   > > [Note: Pathnames containing spaces require special handling by the user to avoid truncation when read by the extractor. — end note]

   > > [Note: The `quoted` function is described in ISO 14882:2014 §27.7.6. — end note]

   > > Returns: `os`

   >     template <class charT, class traits>
   >     basic_istream<charT, traits>&
   >     operator>>(basic_istream<charT, traits>& is, path& p);

   > > Effects:

   > > >     basic_string<charT, traits> tmp;
   > > >     is >> quoted(tmp);
   > > >     p = tmp;

### 21. [PDTS] `directory_entry operator==` needs clarification

Section: X 12.3 [directory_entry.obs] Status: WP Submitter: GB-12 Opened: 2014-01-20 Last modified: 2014-04-18

View all other issues in 12.3 [directory_entry.obs].

View all issues with WP status.

Discussion:

Since `operator==` for `directory_entry` does not check status, it would be worth highlighting that `operator==` only checks that the paths match.

Suggested action:

Add: [Note: does not include status values — end note]

[2014-02-09, Beman Dawes suggest wording]

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

Proposed resolution:

To 12.3 [directory_entry.obs] `operator==` add:

[Note: Status members do not participate in determining equality. — end note]

### 24. [PDTS] Incorrect effects clause for path `copy`

Section: X 15.3 [fs.op.copy] Status: WP Submitter: GB-14 Opened: 2014-01-20 Last modified: 2014-04-18

View all issues with WP status.

Discussion:

Incorrect effects clause for path copy — the effect clause for `copy` [fs.op.copy] includes "`equivalent(f, t)`" — there is no `equivalent()` function defined for variables of this type (`file_status`)

Suggested action:

Replace with "`equivalent(from, to)`"

[2014-02-09, Beman Dawes suggests wording]

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

Proposed resolution:

Change 15.3 [fs.op.copy]:

> Report an error as specified in Error reporting if:

> - `!exists(f)`.
> - `equivalent(f, t from, to)`.
> - `is_other(f) || is_other(t)`.
> - `is_directory(f) && is_regular_file(t)`.

### 29. [PDTS] Unclear semantics of `read_symlink` on error

Section: X 15.27 [fs.op.read_symlink] Status: WP Submitter: GB-16 Opened: 2014-01-20 Last modified: 2014-04-18

View all issues with WP status.

Discussion:

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]

I do not believe path() can be a valid return for the overload not taking error_code.

Strike "Otherwise `path()`."

[2014-02-09, Beman Dawes provides wording]

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

Proposed resolution:

Change 15.27 [fs.op.read_symlink]:

> Returns: If `p` resolves to a symbolic link, a `path` object containing the contents of that symbolic link. Otherwise `path()`. The signature with argument `ec` returns `path()` if an error occurs.

> Throws: As specified in Error reporting. [Note: It is an error if `p` does not resolve to a symbolic link. — end note]

### 32. [PDTS] `system_complete()` example needs clarification

Section: X 15.36 [fs.op.system_complete] Status: WP Submitter: FI-10 Opened: 2014-01-20 Last modified: 2014-04-18

View all issues with WP status.

Discussion:

"[Example: For POSIX based operating systems, `system_complete(p)` has the same semantics as `complete(p, current_path())`." What is this `complete` that is referred here?

Clarify the example.

[2014-02-10 Beman Dawes suggests wording]

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

Proposed resolution:

Change 15.36 [fs.op.system_complete]:

> [Example: For POSIX based operating systems, `system_complete(p)` has the same semantics as `completeabsolute(p, current_path())`.

### 33. [PDTS] `unique_path()` is a security vulnerability

Section: X 15.38 [fs.op.unique_path] Status: WP Submitter: CH-19 Opened: 2014-01-20 Last modified: 2014-04-18

View all issues with WP status.

Discussion:

`unique_path()` is a security vulnerability. As the Linux manual page for the similar function `tmpnam()` writes in the "BUGS" section: "Never use this function. Use `mkstemp`(3) or `tmpfile`(3) instead." `mkstemp()` and `tmpfile()` avoid the inherent race condition of `unique_path()` by returning an open file descriptor or `FILE*`.

[Beman Dawes comments: 10 Feb 2014:]

> There are two issues here:

> - 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.
> - Very real security concerns. See issue 54. 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.

[ 2014-02-11 Issaquah: Strike the function. ]

[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.]

Remove this function. Consider providing a function `create_unique_directory()`. If it fits the scope of the proposed TS, consider providing functions `create_unique_file()` that returns `ifstream`, `ofstream` and `iofstream`.

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

[2014-02-10 Beman Dawes]

Previous resolution from Beman [SUPERSEDED]:

> Change 15.38 [fs.op.unique_path]:

>         path unique_pathgenerate_random_filename(const path& model="%%%%-%%%%-%%%%-%%%%");
>         path unique_pathgenerate_random_filename(const path& model, error_code& ec);

> > The `unique_path generate_random_filename` 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.

> > [Note: 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. --end note]

> > Returns: A path identical to `model`, 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 `ec` returns `path()` if an error occurs.

> > Throws: As specified in Error reporting.

> > Remarks: Implementations are encouraged to obtain the required randomness via a cryptographically secure pseudo-random number generator, such as one provided by the operating system. [Note: Such generators may block until sufficient entropy develops. --end note]

> > Replace this example with one that opens a std::ofstream:

> > [Example:

> > >             cout << unique_pathgenerate_random_filename("test-%%%%%%%%%%%.txt") << endl;

> > Typical output would be `"test-0db7f2bf57a.txt"`. Because 11 hexadecimal output characters are specified, 44 bits of randomness are supplied. -- end example]

Proposed resolution:

Remove the two `unique_path` function signatures from 6 [fs.filesystem.synopsis].

Remove 15.38 [fs.op.unique_path] in its entirety.

[This removes all references the function from the working draft.]

### 44. [PDTS] enum classes `copy_options` and `perms` should be bitmask types

Section: X 10.2 [enum.copy_options], X 10.3 [enum.perms] Status: WP Submitter: P.J. Plauger Opened: 2014-01-30 Last modified: 2014-04-18

View all other issues in 10.2 [enum.copy_options].

View all issues with WP status.

Discussion:

enum classes `copy_options` and `perms` should be bitmask types.

[2014-02-08 Daniel comments and suggests wording]

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

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

Proposed resolution:

This wording is relative to SG3 working draft and assumes that LWG 1450 has been resolved.

1. Change [enum.copy_options] as indicated:

   > This enumeration The `enum class` type `copy_options` is a bitmask type (C++11 §17.5.2.1.3) that specifies bitmask constants used to control the semantics of copy operations. The constants are specified in option groups. […]

2. Change [enum.perms] as indicated:

   > This enumeration The `enum class` type `perms` is a bitmask type (C++11 §17.5.2.1.3) that specifies bitmask constants used to identify file permissions.

### 47. [PDTS] `last_write_time()` uses ill-formed cast

Section: X 15.25 [fs.op.last_write_time] Status: WP Submitter: P.J. Plauger Opened: 2014-01-30 Last modified: 2014-04-18

View all other issues in 15.25 [fs.op.last_write_time].

View all issues with WP status.

Discussion:

In `last_write_time`, `static_cast<file_time_type>(-1)` is ill formed, (possibly should be `chrono<unspecified-trivial-clock>::from_time_t(-1))`.

[2014-02-08 Daniel comments and provides wording]

I agree that the current wording needs to be fixed, but it is unclear to me whether invoking `from_time_t` (which is only guaranteed to exist for `std::chrono::system_clock`) with a value of `time_t(-1)` is a well-defined operation. Reason is that the C Standard makes a difference between a calendar time and the value `time_t(-1)` as an error indication. But the specification of `system_clock::from_time_t` only says "A `time_point` object that represents the same point in time as `t` […]" and it is not clear whether `time_t(-1)` can be considered as a "point in time". Instead of relying on such a potentially subtle semantics of the conversion result of `time_t(-1)` to `std::chrono::system_clock::time_point` with a further conversion to `file_time_type` (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 `last_write_time` to one of the well-define limiting values of `file_time_type`, e.g. `file_time_type::min()`.

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

Proposed resolution:

This wording is relative to SG3 working draft.

1. Change the last write time prototype specification, 15.25 [fs.op.last_write_time], as indicated:

   >     file_time_type last_write_time(const path& p);
   >     file_time_type last_write_time(const path& p, error_code& ec) noexcept;

   > > Returns: The time of last data modification of `p`, determined as if by the value of the POSIX `stat` structure member `st_mtime` obtained as if by POSIX `stat()`. The signature with argument `ec` returns `static_cast<file_time_type>(-1)file_time_type::min()` if an error occurs.

### 50. [PDTS] `path::compare(const string& s)` wrong argument type

Section: X 8 [class.path] Status: WP Submitter: Stephan T. Lavavej Opened: 2014-02-03 Last modified: 2014-04-18

View all other issues in 8 [class.path].

View all issues with WP status.

Discussion:

`path` has "`int compare(const string& s) const;`" but it should almost certainly take `const string_type&`, since the third overload takes `const value_type*`.

[2014-02-08 Daniel comments and provides wording]

This issue is the same as 43 and resolves that issue as well.

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

Proposed resolution:

This wording is relative to SG3 working draft.

1. Change class `path` synopsis, 8 [class.path], as indicated:

   >     // compare
   >     int compare(const path& p) const noexcept;
   >     int compare(const string_type& s) const;
   >     int compare(const value_type* s) const;

2. Change `path compare` prototype specification, 8.4.8 [path.compare], as indicated:

   >     int compare(const string_type& s) const;

### 52. [PDTS] Better to avoid deriving from `std::iterator`

Section: X 13 [class.directory_iterator], X 14 [class.rec.dir.itr] Status: WP Submitter: Stephan T. Lavavej Opened: 2014-02-03 Last modified: 2014-04-18

View all other issues in 13 [class.directory_iterator].

View all issues with WP status.

Discussion:

Although the Standard has made this mistake almost a dozen times, I recommend not depicting `directory_iterator` and `recursive_directory_iterator` as deriving from `std::iterator`, 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 `is_base_of`, not that they should be asking that question.)

[2014-02-08 Daniel comments and provides wording]

This issue is basically similar to the kind of solution that had been used to remove the requirement to derive from `unary_function` and friends as described by N3198 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 `regex` related iterator don't derive from `std::iterator` either.

Another reason to change the current specification is the fact that it currently says that the member types `pointer` and `reference` would be determined to `value_type*` and `value_type&` (that is mutable pointers and references), which conflicts with the specification of the return types of the following members:

>     const directory_entry& operator*() const;
>     const directory_entry* operator->() const;

The proposed fording fixes this by correcting these `typedef` to corresponding `const` access.

The very same objections had been expressed by issue 51 and the below given wording resolves this issue as well.

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

Proposed resolution:

This wording is relative to SG3 working draft.

1. Change class `directory_iterator` synopsis, [class.directory_iterator], as indicated:

   >     namespace std { namespace tbd { namespace filesystem {

   >           class directory_iterator :
   >             public iterator<input_iterator_tag, directory_entry>
   >           {
   >           public:
   >             typedef directory_entry        value_type;
   >             typedef ptrdiff_t              difference_type;
   >             typedef const directory_entry* pointer;
   >             typedef const directory_entry& reference;
   >             typedef input_iterator_tag     iterator_category;

   >             // member functions
   >             […]
   >           };

   >     } } }  // namespaces std::tbd::filesystem

2. Change class `recursive_directory_iterator` synopsis, [class.rec.dir.itr], as indicated:

   >     namespace std { namespace tbd { namespace filesystem {

   >           class recursive_directory_iterator :
   >             public iterator<input_iterator_tag, directory_entry>
   >           {
   >           public:
   >             typedef directory_entry        value_type;
   >             typedef ptrdiff_t              difference_type;
   >             typedef const directory_entry* pointer;
   >             typedef const directory_entry& reference;
   >             typedef input_iterator_tag     iterator_category;

   >             // constructors and destructor
   >             […]

   >             // modifiers
   >             recursive_directory_iterator& operator=(const recursive_directory_iterator&) = default;
   >             recursive_directory_iterator& operator=(recursive_directory_iterator&&) = default;

   >             const directory_entry& operator*() const;
   >             const directory_entry* operator->() const;

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

   >             […]
   >           };

   >     } } }  // namespaces std::tbd::filesystem

### 55. [PDTS] Clarify Error reporting

Section: X 7 [fs.err.report] Status: WP Submitter: Beman Dawes Opened: 2014-01-20 Last modified: 2014-04-18

View all issues with WP status.

Discussion:

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.

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

Proposed resolution:

Change 7 [fs.err.report]:

> Functions not having an argument of type `error_code&` report errors as follows, unless otherwise specified:

> - 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 `filesystem_error` shall be thrown. For functions with a single path argument, that argument shall be passed to the `filesystem_error` constructor with a single path argument. For functions with two path arguments, the first of these arguments shall be passed to the `filesystem_error` constructor as the `path1` argument, and the second shall be passed as the `path2` argument. The `filesystem_error` constructor's `error_code` argument is set as appropriate for the specific operating system dependent error.
> - Failure to allocate storage is reported by throwing an exception as described in C++11 § 17.6.4.10.
> - Destructors throw nothing.

> Functions having an argument of type `error_code&` report errors as follows, unless otherwise specified:

> - 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 `error_code&` argument is set as appropriate for the specific operating system dependent error. Otherwise, `clear()` is called on the `error_code&` argument.