Ways to get screwed by C • Hacker News Board

Re: Ways to get screwed by C

#11

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

endgame wrote: post #8

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.

I personally hate an 80 character limit. I do wrap comments at 80 or 100 chars but code isn't read like english prose--It's very easy to read a long line of code and it makes a lot of sense (sometimes) to keep everything on one line. Especially if there are multiple similar lines where you can make the columns line up nicely.

Re: Ways to get screwed by C

#12

Post by alexgartrell » Fri, Dec 10, 2010, 4:01 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…

I think the problem is that a lot of languages encourage you to do something clever, whereas C actively and relentlessly punishes you for being clever.

My favorite example is from #19, which is something that javascript programmers do all of the time.

  int value = a && b && fn(a->x,b->x);

(The author goes on to complain about how value you obviously be whatever fn(a->x, b->x) returns).

In javascript, that's actually good practice (I guess, I had a mentor once who encouraged it, but I never really bought into it). To a C programmer though, that just looks gross. (Or at least to me, and I like to pretend to be a C programmer).

Re: Ways to get screwed by C

#13

Post by staktrace » Fri, Dec 10, 2010, 4:51 AM UTC

Seriously? I think this page reflects more on the person who wrote it than on C. A top 10 list with 19 items? Genius! Forgetting to include a tag on item #6? Classic sign of a sloppy programmer.

Re: Ways to get screwed by C

#14

Post by defen » Fri, Dec 10, 2010, 4:57 AM UTC

Something similar to #17 burned me at my first job. Did you know that if a variable is declared as a "char", the compiler gets to decide whether it's signed or unsigned? (Consistently, of course - every "char" will be signed, or every "char" will be unsigned). I didn't at the time, but I sure do now!

My employer had code that ran on about 5 billion different platforms, and my job was to port it to a new one. Everything went fine, except for the weird random crashes that would happen periodically. The idea that a "char" could be an "unsigned char" by default was so far off my radar screen that I didn't figure out what was going on until a few days later when I reluctantly dived into the assembly. (It didn't help that it was a mobile platform with basically 0 support for gdb).

Turned out to be a 3 second fix - pass "-fsigned-char" to gcc. Nowadays in new code I always explicitly declare whether my chars are signed or unsigned.

Re: Ways to get screwed by C

#15

Post by ScottBurson » Fri, Dec 10, 2010, 5:10 AM UTC

I once ran into a bug of this form (boiled down into a small example):

  struct thing {
    int x;
  } aThing;
  int x;
  aThing,x = 3;

Do you see it?

EDIT: fix typo

Re: Ways to get screwed by C

#16

Post by CamperBob » Fri, Dec 10, 2010, 5:13 AM UTC

The kid who wrote this is really going to enjoy Verilog.

I liked

   int a = 2 && 4 && 8;   // what is the value of "a" ? would you belive a=1 ?

I'm not sure the author has the necessary qualifications to condemn C's "poor design."

Re: Ways to get screwed by C

#17

Post by alecszaharia » Fri, Dec 10, 2010, 5:21 AM UTC

:)

for(i=0;isome code here/ }

Re: Ways to get screwed by C

#18

Post by alecszaharia » Fri, Dec 10, 2010, 5:31 AM UTC

staktrace wrote: post #13

Seriously? I think this page reflects more on the person who wrote it than on C. A top 10 list with 19 items? Genius! Forgetting to include a tag on item #6? Classic sign of a sloppy programmer.

I agree that.

Re: Ways to get screwed by C

#19

Post by ajays » Fri, Dec 10, 2010, 5:44 AM UTC

lint(1) [or splint(1)] is your friend.

Or use "gcc -Werror" when compiling.

C is like a sharp knife: in skilled hands, it can do wonders. Unskilled hands end up missing a finger or two.

Re: Ways to get screwed by C

#20

Post by endgame » Fri, Dec 10, 2010, 6:01 AM UTC

ajays wrote: post #19

lint(1) [or splint(1)] is your friend. Or use "gcc -Werror" when compiling. C is like a sharp knife: in skilled hands, it can do wonders. Unskilled hands end up missing a finger or two.

The problem with -Werror is it causes trouble with autoconf-based scripts: Test programs that should've compiled can fail because of a warning as opposed to an actual error. I prefer to compile with -Wall -Wextra and not commit anything that raises warnings.