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.

Post History

77%

+5 −0

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

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 yo...

posted 3y ago by Lundin‭ · edited 3y ago by Lundin‭

Answer

#3: Post edited by

Lundin‭ · 2021-04-22T15:41:40Z (about 3 years ago)

Copy Link

Raw

Markdown

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](https://clang-analyzer.llvm.org/) which is more mature. Another open-source one is [Frama-C](https://frama-c.com/); 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:
```c
#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:
```c
// 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))
```

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](https://clang-analyzer.llvm.org/) which is more mature. Another open-source one is [Frama-C](https://frama-c.com/); 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:
```c
#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:
```c
// 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.

#2: Post edited by

Lundin‭ · 2021-04-22T14:49:57Z (about 3 years ago)

Copy Link

Raw

Markdown

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](https://clang-analyzer.llvm.org/) which is more mature 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:
```c
#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:
```c
// 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))
```

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](https://clang-analyzer.llvm.org/) which is more mature. Another open-source one is [Frama-C](https://frama-c.com/); 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:
```c
#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:
```c
// 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))
```

#1: Initial revision by

Lundin‭ · 2021-04-22T14:38:26Z (about 3 years ago)

Copy Link

Raw

Markdown

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](https://clang-analyzer.llvm.org/) which is more mature 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:

```c
#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:

```c
// 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))
```

Communities

Post History