std::pair move constructor not standard conformant, potentially dangerous behavior for pair of references - by Valentin Z

Status : 

  Fixed<br /><br />
		This item has been fixed in the current or upcoming version of this product.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.


2
0
Sign in
to vote
ID 696109 Comments
Status Closed Workarounds
Type Bug Repros 0
Opened 10/21/2011 9:40:14 AM
Access Restriction Public
Moderator Decision Sent to Engineering Team for consideration

Description

According to the current standard draft, the effect of pair& operator=(pair&& p) should be:

"Assigns to first with std::forward<first_type>(p.first) and to second with
std::forward<second_type>(p.second)."

What it actually does is:

this->first = _STD move(_Right.first);
this->second = _STD move(_Right.second);

See reproduction below, why may silently break older, existing code.
Sign in to post a comment.
Posted by Microsoft on 11/4/2011 at 7:13 PM
Hi,

Thanks for reporting this bug. We've fixed it, and the fix will be available in VC11. Additionally, I've verified that VC11's tuple was unaffected by this bug, and I've added an exhaustive regression test for pair-to-pair/tuple-to-tuple/pair-to-tuple normal/template move-construct/move-assign when the source's elements are lvalue references.

In the future, please note that it's ideal to file bugs through Connect with self-contained test cases. The best kind is a small source file, compiled on the command line, along with the exact command line used to compile it. In addition to being exceedingly helpful to whoever eventually investigates your bug (whether it's a library dev, compiler dev, etc.), this makes our moderators' lives easier. PJP and I maintain VC's STL, but we're at the end of the Connect pipeline, not the beginning. (In some sense, I am Infinity-Minus-One-tier support, and PJP is Infinity-tier support.) Our moderators initially look at bugs to verify that they can, in fact, be reproduced, then they route them accordingly to the correct team. They're not STL experts and they can't look things up in the Standard, but they can verify that a source file doesn't compile when a customer says it should, or that it compiles but produces output unexpected by the customer. Since I read the Standard for a living, your originally provided information was enough for me, but I don't even see Connect bugs until they're assigned to me through our system.

Thank you again for catching this very subtle problem - I agree that unintentional moving from lvalues is extremely dangerous. If you have any further questions, feel free to E-mail me at stl@microsoft.com .

Stephan T. Lavavej
Visual C++ Libraries Developer
Posted by Microsoft on 10/27/2011 at 1:59 AM
Thanks for your feedback.

We are rerouting this issue to the appropriate group within the Visual Studio Product Team for triage and resolution. These specialized experts will follow-up with your issue.
Posted by Valentin Z on 10/25/2011 at 7:00 AM
Dear Moderators,

the issue is that your shipped STL has a std::move where the standard clearly demands a std::forward. P.J. Plauger from Dinkumware acknowledged this as a bug, too.

As the source code for pair& operator=(pair<_Ty1, _Ty2>&& _Right) in the utility header is just 3 lines of code, I do not understand what kind of demonstration you need to conduct further research. I just attached a simple source file to demonstrate this issue. According to the standard, fooSrc1 and fooSrc2 should not change, i.e. the program should output "1". Using the STL shipped with VS2010, the contents of fooSrc1 and fooSrc2 is moved into fooDst1 and fooDst2, i.e. the program output is "0".

Yours faithfully
Valentin
Posted by MS-Moderator10 [Feedback Moderator] on 10/24/2011 at 1:26 AM
Thank you for submitting feedback on Visual Studio 2010 and .NET Framework. In order to efficiently investigate and reproduce this issue, we are requesting additional information outlined below.

Could you please give us a demo project to demonstrate this issue so that we can conduct further research?

We look forward to hearing from you with this information.

Microsoft Visual Studio Connect Support Team
Posted by MS-Moderator01 on 10/21/2011 at 10:42 AM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(http://support.microsoft.com)