id,summary,reporter,owner,description,type,status,milestone,component,version,severity,resolution,keywords,cc 7873,C4244 in basic_binary_iprimitive.hpp due to std::size_t and std::streamsize type difference,Hamp ,Robert Ramey,"With Visual Studio 2010 a C4244 warning appears in basic_binary_iprimitive.hpp. boost/archive/basic_binary_iprimitive.hpp(181): warning C4244: 'argument' : conversion from 'std::streamsize' to 'size_t', possible loss of data The offending line is the last one in the function, with (count - s) {{{ template inline void basic_binary_iprimitive::load_binary( void *address, std::size_t count ){ // note: an optimizer should eliminate the following for char files BOOST_ASSERT( static_cast(count / sizeof(Elem)) <= boost::integer_traits::const_max ); std::streamsize s = static_cast(count / sizeof(Elem)); std::streamsize scount = m_sb.sgetn( static_cast(address), s ); if(scount != s) boost::serialization::throw_exception( archive_exception(archive_exception::input_stream_error) ); // note: an optimizer should eliminate the following for char files BOOST_ASSERT(count % sizeof(Elem) <= boost::integer_traits::const_max); s = static_cast(count % sizeof(Elem)); if(0 < s){ // if(is.fail()) // boost::serialization::throw_exception( // archive_exception(archive_exception::stream_error) // ); Elem t; scount = m_sb.sgetn(& t, 1); if(scount != 1) boost::serialization::throw_exception( archive_exception(archive_exception::input_stream_error) ); std::memcpy(static_cast(address) + (count - s), &t, s); } } }}} where count is a passed-in std::size_t and s is a local std::streamsize. Ticket #3755 discusses a related issue in the asserts where a signed/unsigned comparison took place. This was resolved by a static_cast in the assert. For Visual Studio 2010, x86, and both Release and Debug, the following '''effective''' typedefs apply {{{ typedef __int64 streamsize; typedef _unsigned int size_t; }}} Since s is set by count, there does not seen to be a risk of overflowing s. Is there any way to prevent the warning? I check the current trunk and the issue would still exist. ",Bugs,closed,To Be Determined,serialization,Boost 1.50.0,Cosmetic,fixed,,