So you think you know C? (2016) • Hacker News Board

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

#121

Post by rayiner » Sat, Jul 06, 2019, 3:51 AM UTC

angleofrepose wrote: post #39

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…

Somewhat related, my introductory classes involved a lot of games around pre- and post- increments and short circuiting. While I get that understanding these operations is fundamentally important, is understanding ridiculous combinations of them important? I mean, these were the basis of large portions of some quizzes and midterms. I get playing with them from a theoretical perspective, as this can literally be done…

The questions are testing whether you really understand the basic rules of the language. Often times, the best way to test whether you really get the rules is to raise them in some odd context, so that you can’t just pattern match to figure out the result.

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

#122

Post by hedora » Sat, Jul 06, 2019, 3:53 AM UTC

ryandrake wrote: post #97

lvturner wrote: post #87

Earlier quoted context omitted.

I took that to be the point of the article though, that just looking at the code wasn't enough to know and you needed to go further to answer these cases for your exact use case or target platform.

Further: Unless your code is compiled, deployed to a rocket, and fired off the Earth never to return, the question of “what is my platform?” is meaningless in the context of writing good C. So, today, using the compiler installed on your system right now, sizeof(int) = 32. Great. That means nothing, and changes nothing about whether your code is correct. You should not write code relying on it. Just like you should n…

This is why, decades ago, the C world moved on, and added types like int32_t and size_t, so programmers can say what they mean.

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

#123

Post by ridiculous_fish » Sat, Jul 06, 2019, 3:59 AM UTC

UB nasal demons etc etc.

But often we encounter UB in code that's already shipped. So it's good to have an intuition about what machine code was actually emitted, for example when deciding if a crash report is due to this particular UB, or not.

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

#124

Post by rgoulter » Sat, Jul 06, 2019, 4:00 AM UTC

zw123456 wrote: post #73

The better wording would be D) not enough information to give a definitive answer. It's like the old gotchya question; what is 1+1 ? of course the answer is it depends on if you are using binary or a base of integer >2.

Yeah, or "undefined behaviour".

But that reminds me of the joke: there are 10 kinds of people: those who know binary, those who don't, and those who didn't know the '10' was written in base 3.

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

#125

Post by microcolonel » Sat, Jul 06, 2019, 4:01 AM UTC

FartyMcFarter wrote: post #68

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

Sure, but portable C programs are not written for systems with 16-bit machine words practically ever anymore. Nobody's expecting to run libopus 1.3.1 unmodified on an 8051 (even if it might well do, it probably uses stdint.h anyway!). Furthermore, I've used toolchains for machines with 16-bit machine words, which made int 32 bits; surely this isn't uncommon.

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

#126

Post by microcolonel » Sat, Jul 06, 2019, 4:05 AM UTC

ghettoimp wrote: post #84

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…

I think this objection boils down to your perspective on what we mean by "C". It's reasonable for some folks (especially working programmers who need to "get stuff done") to think that "what a reasonable compiler in their problem domain" would do is what "C" means. It's equally reasonable for other folks (especially compiler writers, verification experts, researchers, etc.) to think the ISO standard is what "C" means…

> It would be great for the standard to be more "reasonable" and have less undefined behavior.

GCC and Clang are mostly compatible, and as far as the low-hanging fruit is concerned. If you consider them the authority, it generally resolves most interesting questions about what ISO decline to specify. I do not think that there is any great burning need for ISO to go and define things more rigorously.

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

#127

Post by erik_seaberg » Sat, Jul 06, 2019, 4:10 AM UTC

dmcdm wrote: post #116

ryandrake wrote: post #97

Earlier quoted context omitted.

Further: Unless your code is compiled, deployed to a rocket, and fired off the Earth never to return, the question of “what is my platform?” is meaningless in the context of writing good C. So, today, using the compiler installed on your system right now, sizeof(int) = 32. Great. That means nothing, and changes nothing about whether your code is correct. You should not write code relying on it. Just like you should n…

>Unless your code is compiled, deployed to a rocket, and fired off the Earth never to return, the question of “what is my platform?” is meaningless in the context of writing good C. While I feel the tone of your comparison was intended to be a bit hyberbolic, the reality is a bulk of modern C development occurs in a context similar to the one you describe. Further the thought, utterly foreign to the vast majority of…

There is vastly more old C code than new, and it didn't target the x64 or ARM architectures it's running on now. Where it wasn't portable, that was a defect that had to be fixed.

My first job was a 4GL targeting customers running DOS on the 80286, complete with runtime linking. 100% of that work has been abandoned due to incompatibility. It contributed nothing to the profession beyond what I personally learned.

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

#128

Post by School-Cotton » Sat, Jul 06, 2019, 4:11 AM UTC

Tharre wrote: post #36

5/5, but I don't think this test is very good at capturing the more obscure features of C, they all just deal with the fact that platforms have different datatypes/alignment requirements, except for the last one. I think a better example would be the following: int a=1, b=2, i, j; i = a += 2, a + b; j = (a += 2, a + b); Whats the value of a, b, i, j? Hint: i and j are different. Which begs the question, why does C ha…

5 and 7? If I remember the behavior of the comma operator correctly.

Anyway, I am inclined to agree that these are misfeatures. I’d almost certainly ask for it to be changed in code review.

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

#129

Post by graycat » Sat, Jul 06, 2019, 4:12 AM UTC

j = 1

k = 2

i = ++j+++++k++

i = ?

j = ?

k = ?

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

#130

Post by ineedasername » Sat, Jul 06, 2019, 4:12 AM UTC

bandushrew wrote: post #102

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

"I cant know" is a subset of "I dont know" "I dont know" was absolutely the correct answer.

Except from the perspective of a pragmatics linguistic analysis, "I don't know" has a social context of "There's an answer, and I don't know it."

In this case, a non-C programmer should answer "I don't know" to all of them. A person with a passing familiarity should answer similarly. A seasoned pro would be forced to answer the same. Making it a rather useless tool for distinguishing people who think they know C but are honest when faced with their limitations or those who truly know it and know the answer is undetermined, which is supposed to be the point of the exercise.