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

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

#81

Post by bsder » Sat, Jul 06, 2019, 2:55 AM UTC

dmcdm wrote: post #53

I found it an amusing excrcise, if not terribly relevant, even as someone who spends 90% of his dev time in C. What rubs me about these sorts of articles is they make some presumption about the importance and nessecisity of writing truely portable C, as if the "C Standard" were in and of itself a terribly useful tool. This is in contrast to where I live most of the time which is "GCC as an assembler macro language" (…

> This is in contrast to where I live most of the time which is "GCC as an assembler macro language"

And then people like you whine and cry when the gcc compiler suddenly enforces that something is actually undefined and blows away a big chunk of your code in optimization.

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

#82

Post by Filligree » Sat, Jul 06, 2019, 2:57 AM UTC

pksadiq wrote: post #47

Dylan16807 wrote: post #43

Earlier quoted context omitted.

> So the answer is "Undefined." The code is undefined, but "I don't know." is still the correct answer for what happens to the variable.

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

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

#83

Post by gravypod » Sat, Jul 06, 2019, 2:57 AM UTC

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.

Unfortunately the "best answer" is taken to mean "the wrong answer that the teacher programmed into you".

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

#84

Post by ghettoimp » Sat, Jul 06, 2019, 2:58 AM UTC

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. But I, for one, cannot think of a more horrible, thankless chore than actually trying to make that happen. So much code is written in "C", and there are so many compilers and platforms, modern and legacy, that "C" runs on, each with their own notion of "reasonable," that it will take an incredible amount of work.

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

#85

Post by pcwalton » Sat, Jul 06, 2019, 3:01 AM UTC

dmcdm wrote: post #53

I found it an amusing excrcise, if not terribly relevant, even as someone who spends 90% of his dev time in C. What rubs me about these sorts of articles is they make some presumption about the importance and nessecisity of writing truely portable C, as if the "C Standard" were in and of itself a terribly useful tool. This is in contrast to where I live most of the time which is "GCC as an assembler macro language" (…

If you use C as an assembler macro language, you aren't actually writing C. You're likely to get burned someday, unless you compile at -O0.

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

#86

Post by thedufer » Sat, Jul 06, 2019, 3:03 AM UTC

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.

With what compiler? Targeting what architecture? The question is underspecified. "I can't know" is correct.

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

#87

Post by lvturner » Sat, Jul 06, 2019, 3:03 AM UTC

stefan_ wrote: post #75

dmcdm wrote: post #53

I found it an amusing excrcise, if not terribly relevant, even as someone who spends 90% of his dev time in C. What rubs me about these sorts of articles is they make some presumption about the importance and nessecisity of writing truely portable C, as if the "C Standard" were in and of itself a terribly useful tool. This is in contrast to where I live most of the time which is "GCC as an assembler macro language" (…

Where the author goes wrong is in assuming that somehow "I don't know" can be a final answer to these things. No, it is absolutely fucking vital that you know how the compiler will pad your structures in C. Similarly to the "what size is an int" on your architecture - on an ATmega8 this is 16 bit, but the chip can't actually do all 16 bit operations in single instructions.

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.

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

#88

Post by TazeTSchnitzel » Sat, Jul 06, 2019, 3:04 AM UTC

kristopolous wrote: post #37

This is a perfect example of what I hate about some tests. Didn't quite know the purpose of the test, there's a difference between code for any machine and any compiler and gcc running on some vanilla x86, which is pretty common, and could have been the content (ex: you say it's undefined, that's obvious, everyone knows that already, but it's still deterministic... Here's a breakdown of what happens in practice, blah…

But the test doesn't ask about C as compiled by X compiler on Y architecture. It just asks about C.

(You also seem to be assuming GCC is more predictable about undefined behaviour than it actually is.)

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

#89

Post by dingo_bat » Sat, Jul 06, 2019, 3:04 AM UTC

I feel like the test is inaccurate. Each of those snippets has an output that can be repeated by anybody using gcc on x86. So unless you are on some exotic hardware, none of the answers is "I don't know". And if you are using a power pc or something then you should specify that.

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

#90

Post by mikeash » Sat, Jul 06, 2019, 3:04 AM UTC

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.

And then you update your compiler and something completely different happens.