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

So you think you know C? (2016)

wordsandbuttons.online

Post reply on HN
Print view View original

61–70 of 344 posts

Re: So you think you know C? (2016)

#61

Post by jonathankoren »

pksadiq wrote: post #30

There are a few problems with the questionnaire. "I don't know" is pretty generic choice to be given/choosen. Say for example, in question 5, the statement "return i++ + ++i;" is undefined, because the value of i is read and modified twice in a single sequence point (and of course, the order of addition is unspecified), which is not allowed in C. So the answer is "Undefined." (The explanation given in the page not ac…

It’s not just that stuff. What pissed me off was asking about the return code of a comparator. That’s just bad form. You’re only supposed to check for zero or nonzero. I have never used the value beyond that, and if you are, that’s a problem.

Re: So you think you know C? (2016)

#62

Post by ryandrake »

ioquatix wrote: post #49

On a typical modern arch, there are consistent and reasonable answers: 1. 8 ( https://godbolt.org/z/Udcuj0 ) 2. 0 ( https://godbolt.org/z/kZz1YQ ) 3. -96 ( https://godbolt.org/z/1Xq_Oo ) 4. 1 ( https://godbolt.org/z/MIo0s_ ) 5. 2 ( https://godbolt.org/z/J0dsVW ) I agree, you can argue that it's unspecified, undefined, or whatever. It might not be well defined by the C specification, but none of these programs produce…

Sorry, but it’s this kind of attitude that leads to impossible-to-port code, platform lock-in, subtle bugs when tool chains change, and worst case: buffer overflows and outages. These programs may today produce “well defined” output on your favorite systems, but that doesn’t change the fact that it is invoking various flavors of undefined, implementation-defined behavior. It’s not safe C just because it works for me.

It’s an unfortunate truth that programming in the real world involves programmers who dare to explore these corners of C and claim to have answers to these questions. Stay away! Knowing C means knowing what is not defined as much as knowing what is.

Re: So you think you know C? (2016)

#63

Post by _kst_ »

ioquatix wrote: post #49

On a typical modern arch, there are consistent and reasonable answers: 1. 8 ( https://godbolt.org/z/Udcuj0 ) 2. 0 ( https://godbolt.org/z/kZz1YQ ) 3. -96 ( https://godbolt.org/z/1Xq_Oo ) 4. 1 ( https://godbolt.org/z/MIo0s_ ) 5. 2 ( https://godbolt.org/z/J0dsVW ) I agree, you can argue that it's unspecified, undefined, or whatever. It might not be well defined by the C specification, but none of these programs produce…

No, for the cases that involve undefined behavior, the results can differ arbitrarily depending on compiler settings, optimization settings, the presence of seemingly irrelevant code, or, in principle, the phase of the moon.

The behavior of any program that evaluates `i++ + ++i` is undefined. The solution is not to find out how it happens to behave in some circumstances. It's to find clearer code that expresses whatever the original intent was.

Re: So you think you know C? (2016)

#64

Post by WalterBright »

usr1106 wrote: post #21

I failed on one, number 4. I bravely assumed 16 bit integers cannot exist. Can anyone name a concrete platform/compiler where int is/was 16 bit. Or is this just a theoretical option left open by the spec?

Digital Mars C and C++ for DOS and (early) Windows.

Re: So you think you know C? (2016)

#66

Post by begriffs »

Ididntdothis wrote: post #5

Failed all of them. I totally agree with what the author is writing. Don’t presume anything but measure. I also tend to code in a way that it’s not necessary to know all the intricacies. Its not as clever as many like and often makes for longer code but is usually easier to read.

Rather: don't presume anything, read the language specification for the version you are writing (C89, C99, etc).

"Measuring" is exactly the wrong thing to do because often it is indicative of only your specific architecture/compiler.

Re: So you think you know C? (2016)

#68

Post by FartyMcFarter »

microcolonel wrote: post #56

In practice, things in C are not as undefined as the ISO working group specifies them. It is virtually inconceivable that a mainstream compiler stack would do anything other than what you'd expect with example four. As for struct alignment, that's something that most C programmers should know is implementation-defined (which is one of the reasons we even have sizeof to begin with, apart from the mere convenience of i…

> It is virtually inconceivable that a mainstream compiler stack would do anything other than what you'd expect with example four.

I disagree.

I can easily conceive of a (compiler, architecture, compiler options) tuple that simply crashes with an error at compile time or runtime with that code. Namely, some compiler for a 16-bit architecture with "sanitization" options enabled and optimizations disabled.

Integer overflow is one of the easiest "undefined behavior" cases to identify with mechanical checks. Much easier than bounds checking for example, where a general solution is quite tricky.

Re: So you think you know C? (2016)

#70

Post by erik_seaberg »

ioquatix wrote: post #49

On a typical modern arch, there are consistent and reasonable answers: 1. 8 ( https://godbolt.org/z/Udcuj0 ) 2. 0 ( https://godbolt.org/z/kZz1YQ ) 3. -96 ( https://godbolt.org/z/1Xq_Oo ) 4. 1 ( https://godbolt.org/z/MIo0s_ ) 5. 2 ( https://godbolt.org/z/J0dsVW ) I agree, you can argue that it's unspecified, undefined, or whatever. It might not be well defined by the C specification, but none of these programs produce…

You have to know what the standard allows because every optimizer change tries to be more aggressive without violating it. People have been bitten by error checks whose object code was elided because the error "can't happen". You have to decide whether you need code that will always work, or code that seemed to work for a while.
Post reply on HN