CODEWITHSUNDEEP
c++64-bit
busfahrer
busfahrer

Reputation: 221

How to avoid size_t to int casting warnings when porting to 64 bit?

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?

Upvotes: 8

Views: 1581

Answers (3)

AndreyKarpov
AndreyKarpov

Reputation: 999

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.

Upvotes: 0

Marek R
Marek R

Reputation: 37512

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.

Upvotes: 1

anatolyg
anatolyg

Reputation: 28241

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.

Upvotes: 3

Related Questions