Hacker News Reader

Comment by saghm | Hacker News Reader

> Yes, this is a problem of weak static typing of pure C. Pure C is a great tool for some jobs, but here be dragons, as they say.

> The problem is that (sizeof(struct ...)!=0)==1, so size=1 always for memcmp(). Instead of comparing two tmp, my code compared only 1 byte of each structs.

This isn't just due to the type coercion of the third argument to memcmp though, is it? It's at least as much due to the fact that the _return value_ of memcmp is a valid `if` condition. I know that "zero is false, everything else is true" for integers is just as much a "feature" of C as the coercion of the comparison to a size_t, but I feel like it's less obviously a useful feature, given how easily it is to just manually write `!= 0` if you happen to want the existing behavior. Are there any compiler warnings or hints for being able to disallow this specifically?

View on HN

C didn't even have a separate `bool` type until C99 (https://en.cppreference.com/w/c/types/boolean), and even then `true` is simply a macro that expands to 1. The widespread use of int to represent booleans in legitimate code makes it impractical to warn about this practice (at least in existing code).

Most of the linters I'm aware of do the opposite. You could probably create rules for one that require the condition of an if statement to always contain a comparison, but it's worth remembering that the comparison operators themselves return 0 and 1.

> You could probably create rules for one that require the condition of an if statement to always contain a comparison, but it's worth remembering that the comparison operators themselves return 0 and 1.

Yep! I'm thinking that it might be possible to approach it from the side of how the expression is constructed rather than what it actually yields when evaluated though. I'm not positive, but my instinct is that it should at least be technically possible to statically detect whether or not a condition was constructed from a set of recursive rules like this:

    1. `true` or `false` from std.bool.h
    2. a variable or struct field of type `bool` from stdbool.h
    3. a comparison expression using either equality or inequality operators
    4. some composition of instances of these rules with boolean operators
    5. a function call where all returned values are instances of these rules (applied transitively across nested function calls)

There might be a couple other cases where known booleans could potentially be constructed. Off the top of my head, macros could probably be supported by doing this check after the preprocessor rather than before, but I imagine it might not be possible to handle things like invocation of a function pointer. My point is more that I think it would be possible to enumerate almost all of the possible cases. I imagine few existing C codebases would be able to pass that lint fully today, but it would probably be fairly easy to enforce it on a new codebase from day one without too many issues (and if there are occasional outliers like function pointers they could potentially just be individually suppressed rather than allowing violations globally across the project).

Reply on news.ycombinator.com