Run-Time Check Failure #1 in feed_args.hpp using Visual Studio 2010

[Rüdiger Brünner <rbruenner@…>]

Hello,

the statement

size_type res_size = (std::min)(

static_cast<size_type>(specs.truncate_ - !!prefix_space), buf.pcount() );

on line 166 ff. causes an error message in Debug mode in VS 2010 when run-time checks are enabled:

"Run-Time Check Failure #1 - A cast to a smaller data type has caused a loss of data. If this was intentional, you should mask the source of the cast with the appropriate bitmask. For example:

char c = (i & 0xFF);

Changing the code in this way will not affect the quality of the resulting optimized code."

The value of specs.truncate_ (64 bits) is LLONG_MAX that is going to be cast down to a size_t (32 bits). This causes that warning. Would it be feasible to initalise the truncate_ member to INT_MAX on 32 bit systems to avoid this issue?

This message is *very* annoying since it pops up very frequently.

Best regards Rüdiger

[Steven Watanabe]

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.

[Rüdiger Brünner <rbruenner@…>]

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@…]

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@…]

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]

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@…]

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]

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]

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@…]

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]

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]

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]

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@…]

The problem still exists in Boost 1.58.

[adam.f.badura@…]

The problem still exists in Boost 1.58.

[anonymous]

The problem still exists in Boost 1.63

[anonymous]

The problem still exists in Boost 1.63

[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]

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]

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

[James E. King, III]

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