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
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Q&A

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.

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

Parent

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.

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

1 comment thread

General comments (2 comments)
Post
+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.

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

1 comment thread

General comments (3 comments)
General comments
Quasímodo‭ wrote almost 3 years ago

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.

Lundin‭ wrote almost 3 years 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.

dmckee‭ wrote almost 3 years 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.