std::find incorrectly uses memchr - by carstenh_in

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.

Sign in
to vote
ID 703165 Comments
Status Closed Workarounds
Type Bug Repros 0
Opened 11/13/2011 4:16:09 PM
Access Restriction Public


I have a std::vector<char>, call it v. It has been filled from a binary file (a JPEG file in fact).
If I make a call like
auto pos = std::find(v.cbegin(), v.cend(), 0xFF);
then pos == v.begin() (the first byte of a JPEG is 0xFF).
However *v.begin() == 0xFF is false.
That violates 25.1.2 in the 98 C++ Standard.

Stepping through the code it appears that when using cbegin/cend the code for std::find uses memchr. That is incorrect as memchr typecasts the value parameter to unsigned char.
Sign in to post a comment.
Posted by Microsoft on 10/9/2012 at 4:47 PM
Hi again,

We've fixed this bug, and the fix will be available in the next update to our C++ Standard Library implementation.

I rewrote find() so that it's now simultaneously much more aggressive about activating the memchr() optimization, and exhaustively correct given all possible inputs. This includes the special case where, for example, 0xFFFFFFFFUL is outside the [-128, 127] range of signed char, but is equal to the signed char -1 anyways (thanks to the usual arithmetic convernsions).

Posted by Microsoft on 6/18/2012 at 2:18 PM

Thanks for reporting this bug. I'm Microsoft's maintainer of the STL, and I wanted to let you know that while this bug remains active in our database, it won't be fixed in VC11 RTM (VS 2012 RTM). All bugs are important to us, but some are more severe than others and rise to the top of our priority queue.

I'm copying-and-pasting this response across all of the STL's active Connect bugs, but the following terse comments apply specifically to your bug:

* Although the code has behaved like this for a while, I agree that the memchr() optimization is incorrect - we will need to rework it so that the optimization doesn't affect the observable behavior.

I can't promise when we'll be able to resolve this bug, but we hope to do so as soon as possible (and I'll send another response when that happens) - our first opportunity will be the "out of band" release between VC11 and VC12 that Herb Sutter announced at the GoingNative 2012 conference.

Note: Connect doesn't notify me about comments. If you have any further questions, please E-mail me.

Stephan T. Lavavej
Senior Developer - Visual C++ Libraries
Posted by MS-Moderator07 [Feedback Moderator] on 11/13/2011 at 7:15 PM
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 MS-Moderator01 on 11/13/2011 at 4:42 PM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(