Ways to get screwed by C

I don't think they even make compilers that don't warn about the top 2 issues, and 5 for sure. And after that it gets down to "I did something stupid and something stupid happened." I mean:

    int ii = i/++i;

Seriously? As if defining the order of operations would magically take the suck out of that statement.

There are like 1.5 nuggets of real pain in here. (1 point for returning a stack array, 0.5 points for noticing that C is C.)

Re: Ways to get screwed by C

#5

Post by rbranson » Fri, Dec 10, 2010, 3:31 AM UTC

... and I still love C. There's something utterly minimalist and carnal about C. The best part is how it's several orders of magnitude more productive than writing assembly code, all the while 99% as powerful and performant.

Re: Ways to get screwed by C

#6

Post by psyklic » Fri, Dec 10, 2010, 3:42 AM UTC

tedunangst wrote: post #4

Boohoo. I mean it. I don't think they even make compilers that don't warn about the top 2 issues, and 5 for sure. And after that it gets down to "I did something stupid and something stupid happened." I mean: int ii = i/++i; Seriously? As if defining the order of operations would magically take the suck out of that statement. There are like 1.5 nuggets of real pain in here. (1 point for returning a stack array, 0.5 p…

Agreed. Most of these are beginner traps, raise compiler warnings, are very obscure, and/or are simple to avoid if simple conventions are followed.

Re: Ways to get screwed by C

#7

Post by jcsalterego » Fri, Dec 10, 2010, 3:43 AM UTC

1. Non-terminated comment

Use a sane editor with syntax highlighting.

2. Accidental assignment/Accidental Booleans

I always wrap my assignment-conditionals with double parentheses. It sucks when you miss these but I usually type out the right sequence of equal signs when I mean equality.

3. Unhygienic macros

Treat macros like a search-and-replace with a little more intelligence, but respect how literally the pre-processor might take you for. So, add parentheses.

4. Mismatched header files

I've not encountered this before, so I can't comment on it. Be careful with namespaces.

5. Phantom Returned Values

Luckily, gcc -Wall returns: warning: control reaches end of non-void function

6. Unpredictable struct construction

Can't comment on this one either, although I avoid literal assignments given in the example like the plague.

7. Indefinite order of evaluation

The example code just looks messy.

8. Easily changed block scope

Always use curly braces, that's what I say.

9. Permissive compilation

Not sure in the example why one would just remove the CALLIT macro and assume things to work. Of course, the comma in C means something. Not sure why one would put an assignment before a case in a switch either.

10. Unsafe returned values

This is certainly expected!

Re: Ways to get screwed by C

#8

Post by endgame » Fri, Dec 10, 2010, 3:45 AM UTC

pavel_lishin wrote: post #3

At every company I've ever worked, curly braces were mandatory after if/elif/else statements and loops specifically because of #8.

My standard approach is to only ever omit the braces when the entire if statement fits on a single line. I also enforce a hard 80-char limit on my lines, which prevents a single enormous line.

Re: Ways to get screwed by C

#9

Post by dzorz » Fri, Dec 10, 2010, 3:54 AM UTC

> Still not convinced? Try this one (suggested by Mark Scarbrough ):

     #define DEVICE_COUNT 4 
    uint8 *szDevNames[DEVICE_COUNT] = {
            "SelectSet 5000",
            "SelectSet 7000"}; /* table has two entries of junk     
    */

Actually, the remaining two entries are 0, they are not junk.

Re: Ways to get screwed by C

#10

Post by __david__ » Fri, Dec 10, 2010, 3:55 AM UTC

tedunangst wrote: post #4

Boohoo. I mean it. I don't think they even make compilers that don't warn about the top 2 issues, and 5 for sure. And after that it gets down to "I did something stupid and something stupid happened." I mean: int ii = i/++i; Seriously? As if defining the order of operations would magically take the suck out of that statement. There are like 1.5 nuggets of real pain in here. (1 point for returning a stack array, 0.5 p…

Yeah, I was quite underwhelmed by these complaints. Several I don't even think are correct:

#9:

    #define DEVICE_COUNT 4 
    uint8 *szDevNames[DEVICE_COUNT] = {
        "SelectSet 5000",
        "SelectSet 7000"}; /* table has two entries of junk */

"junk" is incorrect. It has 2 entries of zeros, and that is something that you can count on. If you really don't like that (and I generally do like that) you can turn on gcc's -Wextra which will warn about it.

#17 complains about char's being signed but really it should be complaining about chars' signedness not being spec-ed (really--it's implementation dependent whether plain "char" is signed or unsigned. If you really care, use the "signed" keyword. But really, complaining about overflow? Strange.