Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ways to get screwed by C

andromeda.com

Post reply on HN
Print view View original

21–30 of 36 posts

Re: Ways to get screwed by C

#21

Post by alexgartrell »

alexgartrell wrote: post #12
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 g…

(the author goes on to complain about how the value ought to be whatever fn(a->x,b->x) returns)*

That was bad.

Re: Ways to get screwed by C

#22

Post by zzo38 »

CamperBob wrote: post #16

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."

Yes of course I would believe that.

Re: Ways to get screwed by C

#23

Post by zzo38 »

I have never made these kind of mistakes. I have done the things in section 2 and section 19, but I did it on purpose and expected the result, it was not a mistake.

I use Enhanced CWEB for C programming. Many of these things will be caught because you can see in the printout of the book, that there are mistakes. (For example, it typesets octal numbers in italic)

Re: Ways to get screwed by C

#25

Post by endgame »

__david__ wrote: post #11
endgame wrote: post #8

Earlier quoted context omitted.

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.

I personally find that the limit means that you're not occasionally reading far away from the main body of code, which makes it easier for my eyes to track. An added bonus is the ability to put multiple files side-by-side, something not easily possible when lines can be of arbitrary length.

Re: Ways to get screwed by C

#26

Post by Luyt »

When I programmed FORTRAN, there were much uglier things to shoot yourself in the foot with. For example, parameter lists in function calls were not checked: you pass in a double, and the function expects an integer? Good luck with that, the compiler didn't warn about it and no value conversion would take place (the runtime would just interpret part of the bit pattern of the double as an int), and it would probably crash at runtime.

Luckily we have function prototypes in C nowadays ;-)

Re: Ways to get screwed by C

#27

Post by andolanra »

Of the handful of languages I just checked, a fair number of them—especially the popular ones—treat integers starting with 0 as octal. Python 2.6, Ruby, PHP, Perl, Scala, Java and D all believed that 010 == 8, while GHC, GNU Prolog, GNU Smalltalk, Scheme (Guile and Racket) and Common Lisp all treated it as being equal to 10. Python 3 actively rejects it, because they've changed the octal literal syntax to 0o10 to prevent this from sneaking up on people.

Some of the other complaints are valid—for example, I dream of a sensible module system when writing in C, which would alleviate #13—but a lot of the complaints are sort of petty, and I'd argue that this one, being true of many more languages than C, falls directly into the petty bin.

Re: Ways to get screwed by C

#28

Post by unwind »

defen wrote: post #14

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. Everythi…

You're supposed to use chars for character data, in which case it's not supposed to matter whether or not the integer representation is signed or unsigned. All you generally do with characters is store, compare for equality, and print. Those should all be safe to do without ever knowing if the underlying integer is considered signed or unsigned.

It's only when you start doing arithmetic on characters, or just want to use char to mean "byte" (or "octet") that it matters, and then it's a very good idea to be specific and say "unsigned char" if that is what you expect.

Re: Ways to get screwed by C

#29

Post by unwind »

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.

I hope "elif" wasn't mandatory though, people using #define to modify C's syntax are weird. :)

Runs and ducks.

Post reply on HN