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

31–36 of 36 posts

Re: Ways to get screwed by C

#31

Post by wladimir »

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…

Yes, making any assumption on the basic types in C is very dangerous for portability. That's why you should use typedef'd typed such as uint8_t and friends (defined in stdint.h in C99, but easy to roll your own) instead of 'char'. (except in cases where you don't care about the signedness or memory size)

Re: Ways to get screwed by C

#32

Post by wladimir »

jcsalterego wrote: post #7

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-proc…

Yes, the points he makes are typical beginner mistakes, or at least things that 20 years of programmer conventions have found a way around. Not really big problems of the language.

My biggest gripe with C is string handling. Although the extremely insecure functions have been slowly phased out (such as gets), zero-terminated strings are an attack on sanity.

Re: Ways to get screwed by C

#33

Post by gnosis »

wladimir wrote: post #32
jcsalterego wrote: post #7

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-proc…

Yes, the points he makes are typical beginner mistakes, or at least things that 20 years of programmer conventions have found a way around. Not really big problems of the language. My biggest gripe with C is string handling. Although the extremely insecure functions have been slowly phased out (such as gets), zero-terminated strings are an attack on sanity.

"My biggest gripe with C is string handling. Although the extremely insecure functions have been slowly phased out (such as gets), zero-terminated strings are an attack on sanity."

There are some nice safe string libraries out there, like this one:

http://bstring.sourceforge.net/

Re: Ways to get screwed by C

#34

Post by wladimir »

gnosis wrote: post #33
wladimir wrote: post #32

Earlier quoted context omitted.

Yes, the points he makes are typical beginner mistakes, or at least things that 20 years of programmer conventions have found a way around. Not really big problems of the language. My biggest gripe with C is string handling. Although the extremely insecure functions have been slowly phased out (such as gets), zero-terminated strings are an attack on sanity.

"My biggest gripe with C is string handling. Although the extremely insecure functions have been slowly phased out (such as gets), zero-terminated strings are an attack on sanity." There are some nice safe string libraries out there, like this one: http://bstring.sourceforge.net/

Agreed, it is pretty easy to avoid the issue by using a library or framework, and bstring looks nice.

Still, I wish something like that was simply built-in, as external string libraries can cause interoperability issues: Each framework defines its own string handling functions and format, making it neccesary to convert between them in an application, if you use them together.

(the worst thing is that this problem still exists with C++ as of today, even though it has a built-in string people insist on rolling their own)

Re: Ways to get screwed by C

#35

Post by tedunangst »

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…

Funny that you mention it. JavaScript "the bad parts" is a serious contender in the bad language arena.

Re: Ways to get screwed by C

#36

Post by defen »

unwind wrote: post #28
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 t…

Yep. In their defense, this was a codebase with a 20 year lineage that ran on Linux, Solaris, HP-UX, AS/400, all variants of Windows including mobile, Irix, and some that I'm probably forgetting, and they had never run into this issue before.
Post reply on HN