The Top 10 Ways to get screwed by the "C" programming language - old but good

[mouser]

To get on this list, a bug has to be able to cause at least half a day of futile head scratching, and has to be aggravated by the poor design of the "C" language.  In the interests of equal time, and to see how the world has progressed in the 20-odd years since "C" escaped from its spawning ground, see my Top 10 Ways to be Screwed by the Java programming language, and for more general ways to wase a lot of time due to bad software, try my Adventures in Hell page.
1. Non-terminated comment, "accidentally" terminated by some subsequent comment, with the code in between swallowed.
        a=b; /* this is a bug
        c=d; /* c=d will never happen */

...

http://www.andromeda.com/people/ddyer/topten.html


from www.stumbleupon.com

[f0dder]

Gonna read a bit later... the problem you quote is a good example of why syntax highlighting is a wonderful thing, btw. And I wouldn't be surprised if GCC has some option to produce warnings for this...

[Rover]

#1 Way to get screwed by C:  Attempt to learn it!

[f0dder]

Some comments:

#4 should only bite you if you have a bad coding style, or use poorly designed libraries.

#5 will be caught by any decent compiler.

#6 is a bit nasty - endianness is a bother. I believe the standard (or some other "authorative" text), anyway, says something to the effect of "bitfields should only be used for in-memory representations".

#7 is poor coding style and trying to be "cute" rather than clear.

#9 macros are bad - but yeah, C is very permissive.

#10 will be caught by any decent compiler.

#11 looks a bit nasty... but so does the code.

#13 C++ rectifies this somewhat with namespaces. Too bad there's so much legacy code, and too bad #define macros are used for these things (the preprocessor knows nothing about scope, let alone namespaces).

#14 that's the price you pay for trying to use optimal machine-native int size. Go by what the standard says about integer types, and define your own typedefs for when you need specific sizes.

#15 speed over safety... you can always make up your own bounds-checked stuff if you need it. Or move to C++ STL containers.

#16 octal numbers in C suck. They should have made "0o" like there's "0x". Of course in some fonts that will look utterly stupid, but then again, so are those fonts

#17 I agree on that too. IMHO chars should have been unsigned, or perhaps there should have been no "neutral-sounding" types, requiring "sint/uint", "schar/uchar", etc...

[jgpaiva]

Accidental assignment/Accidental Booleans
        if(a=b) c;

I think that's one of those everyone did at some point!
Good read! 

[Eóin]

Accidental assignment/Accidental Booleans
        if(a=b) c;

I think that's one of those everyone did at some point!

I had one of those errors recently. It took the addition of a serious lot of logging code to track down where the error was originating, needless to say when I discovered it was a simple typo I was fit to scream .

[f0dder]

But... "if(a=b) c;" could make sense in "if(a=malloc(FOOBAR) c;"... if you like terse code anyway.

[jgpaiva]

But... "if(a=b) c;" could make sense in "if(a=malloc(FOOBAR) c;"... if you like terse code anyway.

Sure, i already did some code like that, it can be useful. (althought it tends to generate spaghetti-code).
What i meant is that being it a typo or not (sometimes when you're using to different languages at the same time you don't have time to get in the mood of the other one), i think everybody already did that small slip.