Intel® C++ Compiler
Community support and assistance for creating C++ code that runs on platforms based on Intel® processors.
7944 Discussions

Warning 2259: How to suppress legitimate cases?

Stuart_Ferguson
Beginner
684 Views
Warning 2259 can be useful for finding casts from 64-bit ints to 32-ints, but how can I make the message go away once I've confirmed the cast is legitimate? I know I could use pragmas to turn the warning off and back on, but that tends to make the code very hard to read. Is there some idiom I could put in a macro like this?

i32 = VALID_I64_TO_I32_CAST (i64);

Thanks.
0 Kudos
7 Replies
Stuart_Ferguson
Beginner
684 Views
Likewise error 1684. We make many, many legitimate conversions between pointers and ints. I can't seem to find a sequence of casts that will suppress the warning.
0 Kudos
TimP
Honored Contributor III
684 Views
A small example illustrating what you are talking about may help us to proceed with discussion. On the face of it, I don't know why a simple (int) cast shouldn't suppress warnings about assigning (long long) or equivalent to an int.
0 Kudos
Stuart_Ferguson
Beginner
684 Views
Quoting - tim18
A small example illustrating what you are talking about may help us to proceed with discussion. On the face of it, I don't know why a simple (int) cast shouldn't suppress warnings about assigning (long long) or equivalent to an int.

You're right -- it's not happening everywhere. It took a little doing to reproduce, but here's two otherwise identical functions, one that has a 2259 warning and the other that does not. Note that this is a plain C file and requires the "/Wp64" compiler option.

#include

void getInt_WARNING (int *pi)
{
*pi = (int) (time (0) / 60);
}

void getInt_quiet (int *pi)
{
time_t tt;

tt = time (0) / 60;
*pi = (int) tt;
}

This is a big deal for us because the code that generates the warnings is in macro expressions that cannot be re-written in this manner.
0 Kudos
TimP
Honored Contributor III
684 Views
Quoting - Stuart Ferguson

You're right -- it's not happening everywhere. It took a little doing to reproduce, but here's two otherwise identical functions, one that has a 2259 warning and the other that does not. Note that this is a plain C file and requires the "/Wp64" compiler option.

#include

void getInt_WARNING (int *pi)
{
*pi = (int) (time (0) / 60);
}

void getInt_quiet (int *pi)
{
time_t tt;

tt = time (0) / 60;
*pi = (int) tt;
}

This is a big deal for us because the code that generates the warnings is in macro expressions that cannot be re-written in this manner.
Certain recent versions of the compiler tell us that -Wp64 is deprecated i.e. no longer recommended. It seems to have been designed to warn about anything which might behave differently between 32- and 64-bit compilers, but does so at a low level. For example, time_t, after many steps, boils down to a typedef long int in some implementations. In turn, long int would be a 32-bit data type on most 32-bit platforms, but a 64-bit data type on many 64-bit platforms (probably including all those where it is used for time_t), while int is a 32-bit data type on many platforms where long int is 64-bit.
If Wp64 did operate at a higher level, I would have reservations myself about portability of such casts on time_t objects. Noting that difftime() is the safe way to perform arithmetic on time_t objects, I'm a little surprised there aren't more ways to get warnings about this. I don't know how you could assure yourself of never supporting a platform where this would break, unless you run a testsuite to reject platforms where you would run into trouble.
0 Kudos
Stuart_Ferguson
Beginner
684 Views
Quoting - tim18
If Wp64 did operate at a higher level, I would have reservations myself about portability of such casts on time_t objects. Noting that difftime() is the safe way to perform arithmetic on time_t objects, I'm a little surprised there aren't more ways to get warnings about this. I don't know how you could assure yourself of never supporting a platform where this would break, unless you run a testsuite to reject platforms where you would run into trouble.

Well, sure, it may not be a safe cast to perform depending on context. What's odd is that the cast to int is allowed when performed on an int64 variable directly, but generates a warning when the cast is performed on an expression involving int64 values. That seems like a compiler issue.

In any case we'll remove /Wp64 if it is no longer supported.
0 Kudos
Brandon_H_Intel
Employee
684 Views
Quoting - Stuart Ferguson

Well, sure, it may not be a safe cast to perform depending on context. What's odd is that the cast to int is allowed when performed on an int64 variable directly, but generates a warning when the cast is performed on an expression involving int64 values. That seems like a compiler issue.

In any case we'll remove /Wp64 if it is no longer supported.

Stuart, I've submitted a problem report to our front end team to take a look at this. I'm pushing for this warning to be quieted when an explicit cast to int exists.

Microsoft Visual C++* has deprecated /Wp64. We have not though, and our switch is different in behavior from Microsoft's in any event.

Note though that any change in behavior would only likely happen in a future major compiler version. In other words, don't expect this to be addressed in any 11.1 updates.
0 Kudos
jimdempseyatthecove
Honored Contributor III
684 Views

Stuart,

Why not insert the getInt_quiet format into the macro (add the time_t variable). The compiler optimizatons will (should) squish it out.

#define MINUTES(pi) { time_t tt = time (0) / 60; *pi = (int) tt; }

I am guessing at your macro.

Jim Dempsey

0 Kudos
Reply