[llvm-bugs] [Bug 27937] New: codecvt<wchar_t, char, std::mbstate_t>::do_out does not set from_next and to_next correctly on error
via llvm-bugs
llvm-bugs at lists.llvm.org
Mon May 30 04:15:38 PDT 2016
https://llvm.org/bugs/show_bug.cgi?id=27937
Bug ID: 27937
Summary: codecvt<wchar_t, char, std::mbstate_t>::do_out does
not set from_next and to_next correctly on error
Product: libc++
Version: unspecified
Hardware: PC
OS: FreeBSD
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: unassignedclangbugs at nondot.org
Reporter: roel at abittechnical.com
CC: llvm-bugs at lists.llvm.org, mclow.lists at gmail.com
Classification: Unclassified
Created attachment 16436
--> https://llvm.org/bugs/attachment.cgi?id=16436&action=edit
Program that reproduces the issue
I've noticed that our software when building on Mac OS X or FreeBSD with libc++
has a failing test due to std::codecvt<wchar_t, char, std::mbstate_t>::do_out
not properly assigning from_next and to_next when it returns
std::codecvt<wchar_t, char, std::mbstate_t>::error.
I don't have a copy of the final standard, but the draft specification of C++14
I found (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4296.pdf)
says that "It always leaves the from_next and to_next pointers pointing one
beyond the last element successfully converted" in ยง22.4.1.4.2.
If my interpretation of that specification is correct, then I think it's
supposed to convert as many characters as it can and set from_next and to_next
to one position past the last correctly converted character. This is also the
behavior of libstdc++ and MSVC. However, with libc++, from_next and to_next are
placed back in their original position.
I attached a test program that reproduces the issue. The expected output is:
Error!
pwc is now at position: 7
pc is now at position: 7
The actual output is:
Error!
pwc is now at position: 0
pc is now at position: 0
--
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/20160530/30615d6a/attachment.html>
More information about the llvm-bugs
mailing list