Boost C++ Libraries: Ticket #4636: Run-Time Check Failure #1 in feed_args.hpp using Visual Studio 2010

Steven Watanabe — Fri, 11 Feb 2011 04:19:44 GMT

FWIW, I advise against enabling run-time checks, since the result is non-conformant. The behavior of this cast is well defined according to the standard.

Mon, 14 Feb 2011 07:11:58 GMT

Yes, I understand that these run-time checks produce a lot of noise. They are good for finding obscure bugs but I no longer use them permanently.

Best regards

kurt@… — Wed, 02 Mar 2011 21:58:46 GMT

We just ran into this as well. That type check is useful for debugging, and it would be great if Boost played nice with it.

Gordon.Geddes@… — Fri, 06 May 2011 09:46:14 GMT

We've also just come across this problem. By default we run our code in debug with all runtime checks as they can be useful to highlight potential problems but with boost not working with them we're having to switch them off in affected projects. It would be nice if boost did work with these runtime checks.

anonymous — Fri, 21 Oct 2011 05:39:48 GMT

I just ran into this very annoying problem as well.

The cast may be well defined by the standard, but there are quite a few situations where you want to detect overflowing a 32-bit variable with a 64-bit value. So those checks do make sense to me.

I second that it would be nice if boost worked with these checks.

-Matthias

dxc@… — Tue, 29 Nov 2011 12:50:52 GMT

it's still present in boost 1.48.0. we run our regressions on both debug and release builds, and for debug we turn on all the runtime checks. it is well and fine that the standard defines the way the cast is supposed to work, but it is also true that sometimes this runtime check catches a programmer error. we have caught a few corner-cases using this check that otherwise would have been lurking until the customer found it, no doubt at the worst possible time.

sure, I can add the masking trick myself, but 1) not having to mess around in the code is one reason to use high quality libraries; and 2) if *I* patch it now I have to remember to patch every time, and if the code changes this may be non-trivial.

can this really not be fixed? it has been there since at least 1.38 according to the boost users mailing list.

dxc

anonymous — Fri, 01 Jun 2012 19:02:46 GMT

Still there in 1.49. I've told VS2010 to not do any exception checks in Debug mode and it still pops up a dialog box. Very annoying. Works just fine in Release mode, tho'.

anonymous — Mon, 10 Jun 2013 22:03:47 GMT

Still an issue in 1.53. We added the masking trick in when we were using 1.48, but forgot we did when we upgraded and were confused when our unit test failed. Wasted time. Can we please fix this?

emmanuel.andre@… — Wed, 19 Jun 2013 10:01:49 GMT

Same issue here... We had to deactivate runtime checking of overflows for the whole impacted component.

When can we expect a fix ? Do you want that we propose/work on a solution ?

Best regards

timblechmann — Mon, 18 Nov 2013 08:43:41 GMT

very annoying issue. even if the behaviour of the cast may be well defined according to the standard, it would not hurt to implement it explicitly to avoid msvc firing on a potential false positive.

timblechmann — Mon, 18 Nov 2013 09:14:21 GMT

i'd suggest the following patch:

--- a/boost/format/feed_args.hpp
+++ b/boost/format/feed_args.hpp
@@ -21,6 +21,7 @@
 #include <boost/format/format_class.hpp>
 #include <boost/format/group.hpp>
 #include <boost/format/detail/msvc_disambiguater.hpp>
+#include <boost/integer_traits.hpp>
 namespace boost {
 namespace io {
@@ -171,8 +172,8 @@ namespace detail {
                    (res_beg[0] !=oss.widen('+') && res_beg[0] !=oss.widen('-')  ))
                     prefix_space = oss.widen(' ');
             size_type res_size = (std::min)(
-                static_cast<size_type>(specs.truncate_ - !!prefix_space),
-                buf.pcount() );
+                static_cast<size_type>(specs.truncate_ & integer_traits<size_type>::const_max - !!prefix_space),
+                static_cast<size_type>(buf.pcount()) );
             mk_str(res, res_beg, res_size, w, oss.fill(), fl,
                    prefix_space, (specs.pad_scheme_ & format_item_t::centered) !=0 );
         }

anonymous — Sun, 26 Jan 2014 18:50:39 GMT

Hi,

Whether this issue is fixed in latest version of boost library 1.55?.When we apply above mentioned patch is that any thing compromised?. I am facing this issue at run time only. Does the above patch leads to any data loss? Because we are making application level changes to support Unicode format(to support all languages).

i.e wcout<<boost::wformat("My name is %s") %username

adam.f.badura@… — Sun, 07 Jun 2015 18:09:05 GMT

The problem still exists in Boost 1.58.

adam.f.badura@… — Sun, 07 Jun 2015 18:09:58 GMT

The problem still exists in Boost 1.58.

anonymous — Sun, 09 Apr 2017 15:41:18 GMT

The problem still exists in Boost 1.63

anonymous — Sun, 09 Apr 2017 15:41:20 GMT

The problem still exists in Boost 1.63

owner changed

James E. King, III — Wed, 11 Oct 2017 18:56:14 GMT

owner changed from Samuel Krempp to James E. King, III

I am looking into this.

Event without /RTCsuc I am able to see the same thing using a numeric_cast as follows:

            size_type res_size = (std::min)(
                numeric_cast<size_type>(specs.truncate_) - !!prefix_space,
                buf.pcount() );

Which results in the error:

class boost::numeric::positive_overflow: bad numeric conversion: positive overflow

Inspecting it in the debugger I see:

-		specs	{argN_=0 res_="" appendix_="00" ...}	const boost::io::detail::format_item<char,std::char_traits<char>,std::allocator<char> > &
		argN_	0	int
+		res_	""	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		appendix_	"00"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		fmtstate_	{width_=0 precision_=6 fill_=32 ' ' ...}	boost::io::detail::stream_format_state<char,std::char_traits<char> >
		truncate_	9223372036854775807	__int64
		pad_scheme_	0	unsigned int

The offending test is in format_test1.cpp:

  if(str( format("%%##%%##%%1 %1%00") % "Escaped OK" ) != "%##%##%1 Escaped OK00")

At first glance I would say that the value of truncate_ is wrong here, and figuring that out will end up being the root cause.

James E. King, III — Wed, 11 Oct 2017 21:32:49 GMT

format_item::truncate_ uses a std::streamsize which is an unsigned long long type, and it is initialized to a max() value for that type if the format specification doesn't have explicit truncation defined. The code that can make a string (mk_str) has a maximum size of std::string::size_type which is an unsigned long. This impedance mismatch is really the core of the issue here. The code is relying on a clamping mechanism that ensures a cast of the maximum stream size is a useful value when truncated to 32-bits. Therefore it looks like the code in the patch is partially correct; there are other instances that need to be addressed so I will work on this.

James E. King, III — Thu, 12 Oct 2017 01:01:33 GMT

PR is out: https://github.com/boostorg/format/pull/17

keywords, status, milestone changed

James E. King, III — Thu, 12 Oct 2017 01:02:07 GMT

keywords RTC MSVC10 added; format Run-Time Check Failure removed
status new → assigned
milestone To Be Determined → Boost 1.66.0

James E. King, III — Thu, 12 Oct 2017 16:19:40 GMT

Merged into develop, will resolve this when develop merges into master.

status changed; resolution set

James E. King, III — Fri, 20 Oct 2017 16:20:51 GMT

status assigned → closed
resolution → fixed