Every now and then, especially when doing 64bit builds of some code base, I notice that there are plenty of cases where integer overflows are possible. The most common case is that I do something like this:
// Creates a QPixmap out of some block of data; this function comes from library A
QPixmap createFromData( const char *data, unsigned int len );
const std::vector<char> buf = createScreenShot();
return createFromData( &buf[0], buf.size() ); // <-- warning here in 64bit builds
The thing is that std::vector::size() nicely returns a size_t (which is 8 bytes in 64bit builds) but the function happens to take an unsigned int (which is still only 4 bytes in 64bit builds). So the compiler warns correctly.
If possible, I try to fix up the signatures to use the correct types in the first place. However, I’m often hitting this problem when combining functions from different libraries which I cannot modify. Unfortunately, I often resort to some reasoning along the lines of “Okay, nobody will ever do a screenshot generating more than 4GB of data, so why bother” and just change the code to do
return createFromData( &buf[0], static_cast<unsigned int>( buf.size() ) );
So that the compiler shuts up. However, this feels really evil. So I’ve been considering to have some sort of runtime assertion which at least yields a nice error in the debug builds, as in:
assert( buf.size() < std::numeric_limits<unsigned int>::maximum() );
This is a bit nicer already, but I wonder: how do you deal with this sort of problem, that is: integer overflows which are “almost” impossible (in practice). I guess that means that they don’t occur for you, they don’t occur for QA – but they explode in the face of the customer.
If you can’t fix the types (because you can’t break library compatibility), and you’re “confident” that the size will never get that big, you can use
boost::numeric_castin place of thestatic_cast. This will throw an exception if the value is too big.Of course the surrounding code then has to do something vaguely sensible with the exception – since it’s a “not expected ever to happen” condition, that might just mean shutting down cleanly. Still better than continuing with the wrong size.