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

181–190 of 344 posts

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

#181

Post by mytailorisrich »

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…

To me "I don't know" is a very apt choice. It makes the point clear that indeed reading the code does not allow you to know the result, which is quite a pitfall.

In your comment you are jumping from "I don't know", which is the first step, to wanting to explain why.

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

#184

Post by jstimpfle »

pcwalton wrote: post #176
userbinator wrote: post #104

Earlier quoted context omitted.

It's very much worth reading, Linus Torvalds' opinion of standards that's linked in that article, but I'll link it again here: https://lkml.org/lkml/2018/6/5/769 "So standards are not some kind of holy book that has to be revered. Standards too need to be questioned." The way I see it, a lot of compiler writers are basically taking the standard as gospel and ignoring everything else "because the standard doesn't say…

This is a common misconception. Compiler authors don't exploit undefined behavior to make themselves seem smart, or because they like breaking code. They exploit undefined behavior because somebody filed a bug saying some code was slow, and exploiting UB was the simplest way--or, in many cases, the only way--to fix the performance problem. GCC and Clang do give you the option to avoid optimizations based on undefined…

Could you go into a little bit more detail regarding the movzx? Aren't 32-bit registers always zero-extended on x86-64?

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

#185

Post by pcwalton »

jstimpfle wrote: post #184
pcwalton wrote: post #176

Earlier quoted context omitted.

This is a common misconception. Compiler authors don't exploit undefined behavior to make themselves seem smart, or because they like breaking code. They exploit undefined behavior because somebody filed a bug saying some code was slow, and exploiting UB was the simplest way--or, in many cases, the only way--to fix the performance problem. GCC and Clang do give you the option to avoid optimizations based on undefined…

Could you go into a little bit more detail regarding the movzx? Aren't 32-bit registers always zero-extended on x86-64?

Sure. Here's an in-depth explanation from Fabian Giesen: https://gist.github.com/rygorous/e0f055bfb74e3d5f0af20690759...

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

#186

Post by dvdbloc »

pcwalton wrote: post #179
WalterBright wrote: post #160

Having written a conforming C compiler, at one point I knew everything there was to know about C (I forget details now and then, or confusing them with C++ and D). But knowing every engineering detail is not the same thing as knowing how to program in C effectively. It's like being the engineer who designs a Grand Prix car. It does not mean you can drive it faster around the track than anyone else. Not even close. Fo…

I couldn't agree more. After spending many years working with LLVM, which is at its heart a C compiler, and understanding why it has to do the sometimes-terrifying things it has to do to get C to run well, I've become very paranoid when writing C or C++. My C/C++ code is as boring as possible. (In fact I try to avoid writing C or C++ whenever possible these days; undefined behavior in the language is too pernicious a…

What would we write drivers in then if C was obsoleted?

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

#187

Post by gpderetta »

dvdbloc wrote: post #186
pcwalton wrote: post #179

Earlier quoted context omitted.

I couldn't agree more. After spending many years working with LLVM, which is at its heart a C compiler, and understanding why it has to do the sometimes-terrifying things it has to do to get C to run well, I've become very paranoid when writing C or C++. My C/C++ code is as boring as possible. (In fact I try to avoid writing C or C++ whenever possible these days; undefined behavior in the language is too pernicious a…

What would we write drivers in then if C was obsoleted?

pcwalton might have an opinion :). He is Rust lead designer.

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

#188

Post by pcwalton »

gpderetta wrote: post #187
dvdbloc wrote: post #186

Earlier quoted context omitted.

What would we write drivers in then if C was obsoleted?

pcwalton might have an opinion :). He is Rust lead designer.

Not lead designer :)

But yes, Rust, or even in userspace, as newer and/or more microkernel-ish OS's allow for. Apple is doing work to allow drivers to be written in Swift...

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

#189

Post by NohatCoder »

Raymonf wrote: post #19
bcaa7f3a8bbc wrote: post #9

My score is 3/5. One immediate redflag I have noticed is using "int", "char", "short" as if they have a definite size. They don't. C standard only guarantees a minimum size. For example, many PDPs are 36-bit. Assuming the size of a variable is a common practice nowadays, but at least one should use uint8_t, int32_t, etc. from stdint.h. But I was still tricked, it should be obvious in hindsight, 12 years of schooling…

In school, I was taught to choose the "best answer" on a test or quiz, and if you don't know something, choose the answer that looks right to you. This test.. it reverses that entirely.

It is school that gets it wrong. In real life, knowing that you don't know something and acting accordingly is often way better than taking a guess.

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

#190

Post by leni536 »

Filligree wrote: post #82
pksadiq wrote: post #47

Earlier quoted context omitted.

> The code is undefined, but "I don't know." is still the correct answer for what happens to the variable. Well, then a better choice would be "I can't know."

Compile it, look at the assembly. You can know. The answer will vary from place to place, but it isn't non-existent.

UB includes the code not compiling, although it rarely happens in practice.
Post reply on HN