Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users

Dashboard
Notifications
Mark all as read
Q&A

Warn of implicit cast in a function's arguments with GCC?

+5
−0

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.

Why does this post require moderator attention?
You might want to add some details to your flag.
Why should this post be closed?

2 comments

Please note that there is no such thing as "implicit casting". There are implicit and explicit conversions. A cast is always an explicit conversion done by the programmer, by using the cast operator (). There is no casting present in your example. Lundin‭ 22 days ago

Thanks for letting me know. That explains why I could find nothing in the documentation. Quasímodo‭ 22 days ago

2 answers

+5
−0

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.

Why does this post require moderator attention?
You might want to add some details to your flag.

3 comments

Does that mean in the portable C world there is no space for the primitive types anymore (not only int and long)? My impression is that this rarely gets a mention in introduction courses, which is a shame then. Thank you, very instructive answer. Quasímodo‭ 22 days ago

@qsmodo‭ Indeed there are lots of applications where the primitive types are never used and it is common to ban their use in coding standards. Proper introduction courses will address stdint.h. Alternatively you could use the peculiar rules from Modern C/Gustedt, where the recommended types to use are boiled down to size_t, unsigned, signed, double. Now that doesn't work well when writing performance constrained programs for low-end CPUs, but apart from that case, it's not such a bad idea. Lundin‭ 21 days ago

The pointer hack is cute, but to prevent an unintended change in semantics you might pass pointer to const. Of course you'll need a copy if your implementation is changing the passed arguments but you won't inadvertently change values for the calling code. dmckee‭ 20 days ago

+3
−0

From the page you linked:

-Wconversion

Warn for implicit conversions that may alter a value. This includes conversions between real and integer, like abs (x) when x is double; conversions between signed and unsigned, like unsigned ui = -1; and conversions to smaller types, like sqrtf (M_PI). Do not warn for explicit casts like abs ((int) x) and ui = (unsigned) -1, or if the value is not changed by the conversion like in abs (2.0). Warnings about conversions between signed and unsigned integers can be disabled by using -Wno-sign-conversion.

Why does this post require moderator attention?
You might want to add some details to your flag.

0 comments

Sign up to answer this question »