Welcome to Software Development on Codidact!
Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.
Warn of implicit cast in a function's arguments with GCC?
In the C program below, I make a mistake and call the function with (ld, ld) instead of (d, ld).
#include <stdio.h>
#include <limits.h>
void print_int_long(int n, long l){
printf("%+d %+ld\n", n, l);
}
int main(){
int d = 0;
long ld = INT_MAX + 1L;
print_int_long(ld, ld);
return(d);
}
If lucky, such mistakes may be innocuous, but here it is not: Instead of +0 +2147483648 I get -2147483648 +2147483648 because of an integer overflow.
Of course, this is but a dumb example, but I would like to be warned if I make such mistake in a real program. Is there any GCC flag that will detect and warn about this kind of implicit cast? I am used to -Wall -Wpedantic -Wextra but those did not raise a warning. I have also looked in GCC warning options but I failed to find something.
Always open to other approaches too.
2 answers
You are accessing this answer with a direct link, so it's being shown above all other answers regardless of its score. You can return to the normal view.
From the page you linked:
-WconversionWarn for implicit conversions that may alter a value. This includes conversions between real and integer, like
abs (x)whenxisdouble; conversions between signed and unsigned, likeunsigned ui = -1; and conversions to smaller types, likesqrtf (M_PI). Do not warn for explicit casts likeabs ((int) x)andui = (unsigned) -1, or if the value is not changed by the conversion like inabs (2.0). Warnings about conversions between signed and unsigned integers can be disabled by using-Wno-sign-conversion.
0 comment threads
You can use -Wconversion but you should be aware that it is very prone to false positives. It's a good flag to turn on during code review etc to shake out a few minor issues, but it's not a flag you should leave on permanently.
gcc isn't very good at so-called static analysis in the first place. Meaning diagnostic messages that look for potential bugs, beyond the scope of what's required by the C standard. Clang has a static analyser which is more mature. Another open-source one is Frama-C; I have never used it. And there are also plenty of commercial tools of diverse quality.
That being said, the root of your problems is the use of the "naive"/"primitive" default integer types of C. These aren't portable or practical. long could be 4 bytes or it could be 8 bytes. On the most common computers, INT_MAX + 1L is undefined behavior, because they use int=4 bytes, long=4 bytes, long long=8 bytes. So you shouldn't be writing INT_MAX + 1L for that reason.
Instead of worrying about these brittle, non-portable default types, simply use int32_t and int64_t from stdint.h. Your program could be fixed this way:
#include <stdio.h>
#include <limits.h>
#include <stdint.h>
#include <inttypes.h>
void print_int_long(int32_t i32, int64_t i64){
printf("%+"PRIi32 " %+"PRIi64 "\n", i32, i64);
}
int main (void){
int32_t d = 0;
int64_t ld = (int64_t)INT_MAX32 + 1;
print_int_long(d, ld);
}
If you for some reason need to be extra careful with types, you can even do this:
// actual function:
void p_int_long(int32_t i32, int64_t i64);
// public wrapper macro:
#define print_int_long(x,y) \
p_int_long( _Generic((x), int32_t: x), \
_Generic((y), int64_t: y))
EDIT:
Btw if you change the function to take parameters by reference, int* vs long* or int32_t* vs int64_t*, then you get stricter type checking in cases where it matters.
1 comment thread