[llvm-bugs] [Bug 44400] New: _LIBCPP_DEBUG=1 std::string::iterator thinks the end iterator is "non-dereferenceable"

via llvm-bugs llvm-bugs at lists.llvm.org
Sat Dec 28 22:00:16 PST 2019


https://bugs.llvm.org/show_bug.cgi?id=44400

            Bug ID: 44400
           Summary: _LIBCPP_DEBUG=1 std::string::iterator thinks the end
                    iterator is "non-dereferenceable"
           Product: libc++
           Version: unspecified
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: All Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: arthur.j.odwyer at gmail.com
                CC: llvm-bugs at lists.llvm.org, mclow.lists at gmail.com

Bug 41274 may be related somehow.

// https://godbolt.org/z/PeZLZi
int main(int, char**)
{
    std::string In2("abcd/efg");

    std::string::iterator it = In2.end();
    assert(*it == '\0');  // FAILS

    (void) fs::u8path(In2.begin());  // FAILS
}

For something like a std::vector, the "end()" iterator indeed would be
non-dereferenceable. But for a std::string, the "end()" iterator points to the
null terminator, which is a valid character. There is at least one libc++ test
that relies on being able to dereference the "end()" iterator of a std::string:

libcxx/test/std/input.output/filesystems/class.path/path.nonmember/path.factory.pass.cpp

Possible resolutions include:
- Make the one-character fix to basic_string::__dereferenceable (change < to
<=).
- Rewrite `fs::u8path` so that it doesn't try to read the null terminator.
(This is physically impossible, I think?)
- Decide that the current "path.factory.pass.cpp" has UB and eliminate it from
the test suite (perhaps with accompanying LWG issue about this trap for the
unwary).

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20191229/15dda778/attachment.html>


More information about the llvm-bugs mailing list