8

I have to convert a very large C++ legacy code base to 64 bits. I‘ve managed to get one of the base modules to compile, but even in that small module I get 800 warnings of:

warning C4267: = conversion from size_t to int, possible loss of data

I understand why these appear, but what are my options for getting rid of them? Is there any systematic way that avoids touching every single instance?

Dorian Turba
  • 3,260
  • 3
  • 23
  • 67
busfahrer
  • 211
  • 1
  • 8
  • You could probably get your answer here https://stackoverflow.com/questions/6578048/size-t-vs-int-warning. You could ignore the warnings if you think the value does not go beyond 2,147,483,647(MAX_INT), else I dont see an easy way out without touching every instance. – Shrikanth N Jul 10 '19 at 09:39
  • There are two distinct issues: The rank of the integral types as well as their signedness. Your warning is largely about the rank issue. For more ideas with both the rank and the signedness issue, also consider this question its answers: https://stackoverflow.com/questions/275853/acceptable-fix-for-majority-of-signed-unsigned-warnings – Adrian McCarthy Jul 31 '19 at 20:44

3 Answers3

3

One option is to disable the "loss of data" warning. To limit the effect of disabling the warning, MS Visual Studio has push and pop directives:

#pragma warning(push)
#pragma warning(disable: 4267)
// legacy code
#pragma warning(pop)
// normal code

These #pragma directives are specific to Visual Studio; you might want to wrap them with #ifdef _MSC_VER.

anatolyg
  • 26,506
  • 9
  • 60
  • 134
1

This is thought. I'm pretty sure +90% of those warning can be ignored. I had similar problem and lots of warning on something like this:

sumeType tab[10];
int items = std::size(tab);
// or
functionWhichExeptsInt(std::size(tab))

In above example since std::size is a constexpr compiler could just detect that size value is small enough to fit into int so it should not report an warring but it does.

Problem is that there might be a cases where this warning can detect a real issue. So disabling this warning is not a good approach.

In my project we have decided to keep warring, but do not threat it as an error:

  • we reviewed them quickly, if something could be fixed by minimum change we did that
  • when required change was more complex, we just estimated potential danger of having a bug (after all we changed app from 32 to 64 bits to gain access to more memory). If didn't see a risk, we just ignore it for now
  • we fix remaining warnings as code changes and we do not rash to fix them all now.

This is more like mental problem: "Can I ignore those +100 warning for now?". I also love code without warnings reported, but some times it is better to live with them.

IMO this is more safe approach.

Marek R
  • 32,568
  • 6
  • 55
  • 140
0

To search and eliminate bugs, occurring when porting a system from 32-bit to 64-bit, it's rational to use the PVS-Studio specialized tool. It is a static code analyzer which has a certain set of diagnostics (Diagnosis of 64-bit errors). Read here about issues when porting.

The analyzer will also issue V103 warnings when size_t is implicitly cast to int. But unlike the compiler it does it in a smarter way. It doesn't complain about everything. If it is aware that the range of the source value is small, it will be quiet.

Example:

for (size_t i = 0; i < 10; i++)
{
  int x = i; // i == [0..9], OK!
  //....
}

Yes, false positives will still occur, but there will be much less of them. In addition, the analyzer provides a large number of options to suppress false positives.

AndreyKarpov
  • 1,083
  • 6
  • 17
  • Will be happy to try out PVS. For full disclosure, it's good to note your affiliation with the tool. – valiano Jul 14 '19 at 21:02