2009-08-20

Retarded coding standards?

I just stumbled upon this strange blog post that appears to affirm that the following code:

#include 
int main() { std::cout << "Hello, world" << std::endl; }

... is full of "errors," according to the poster's interpretation of MISRA C++ and LINT.

Those are not errors in code; those are design flaws in either the spec for the standard or LINT.

1. The “int” in “int main” violates an advisory rule to avoid using built-in types and instead use typedefs indicating the size and signedness of the type, such as int32_t, INT or signed32T.

main(int,char**) returns an int. Not an int32_t or an int16_t depending on the platform, but an int, which happens to be an int16_t, an int32_t or an int64_t depending on the platform. This is Unix semantics. The resulting value is an error code, not an integer meant to be calculated upon and subject to overflow. At worst it's a small binary set, again not subject overflow. It has been so since C and Unix exist. Ignoring it is just strange.

2. The first left shift operator violates a MISRA rule disallowing the use of bitwise shift on signed types, or so it does according to LINT

ostream & operator<< (const char *) is not the bit shift operator. It is an operator alright. It does not, however, perform a bit shift. Therefore, it is not the bit shift operator. The bit shift operator is (for example) int operator<<(int).

Furthermore, the meaning of said operator is clearly defined for signed integers. Why not disallow substraction on unsigned types, while they're at it? That should prevent underflow!

The two left shift operators as a whole are reported to violate the rule disallowing dependence on C operator precedence [and add parenthesis everywhere]

This is simply crazy. This kind of blanket rules are completely, utterly idiotic. '<<' here is much more readable without parenthesis, esp. considering that there is no other operator that could preempt it.

And anyone who's graduated grad school, even last of his class, knows that 1+2*3 == 1+(2*3) != (1+2)*3. And anyone who's graduated from junior high knows that 1/2/3 is fishy. And what about expressions with just one commutative operator? Are we to add parenthesis to 1+2+3?

I don't know who's to blame here, if the LINT tool is really that clueless or if the MISRA standard mandates this behaviour, but I can't begin to understand how you can ignore long standing (25+ years!) C and C++ idioms. If they don't like operator overloading, why don't they remove them altogether and call it Java?