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

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

#131

Post by School-Cotton » Sat, Jul 06, 2019, 4:13 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…

C compilers predate the C standard by many years, so “C is what my compiler does” is certainly a valid perspective.

Also, the vast majority of programming languages don’t have standards at all, and people still use them productively.

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

#132

Post by bzbarsky » Sat, Jul 06, 2019, 4:17 AM UTC

saagarjha wrote: post #109

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…

> compiler writers are basically taking the standard as gospel I would be rather disappointed if they didn't, honestly.

Consider the following statements:

1) The standard says I must do this, so I must do it.

2) The standard doesn't say I must not do this (but does allow me to either do it or not do it), so it's totally OK if I do it.

I think you're thinking of cases covered by statement 1, and I think pretty much everyone agrees that compiler writers should behave that way for the standard to mean anything.

The issues arise in cases covered by statement 2. Just because the standard allows a behavior doesn't mean that the behavior is a good one. And yes, code relying on you not having the behavior is not following the standard, and that's something the authors of that code should consider addressing. But on the other hand, the standard may allow a lot of behaviors that only make sense in some situations but not others (totally true of the C standard, depending on the underlying hardware) and as a compiler writer you should think carefully about what behaviors you actually want to implement.

AS a concrete example, you _could_ write a C compiler targeting x86-64 which has sizeof(uint64_t) == 1, sizeof(unsigned int) == 1, sizeof(unsigned long) == 2, and sizeof(unsigned long long) == 2 (so 64-bit char, 64-bit short, 64-bit int, 128-bit long, 128-bit long long). Would this be a good idea? Probably not, unless you are trying to use it as a way to test for bugs in code that you will want to run on an architecture where those sizes would actually make sense...

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

#133

Post by pflanze » Sat, Jul 06, 2019, 4:21 AM UTC

What are the best strategies to cope with the undefined areas in C?

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

#134

Post by bzbarsky » Sat, Jul 06, 2019, 4:21 AM UTC

OldHand2018 wrote: post #77

danbolt wrote: post #11

At the end of the test, the author talks about automation programming for a nuclear power plant. I don’t think I could ever sleep the same at night after writing something like that.

> I don’t think I could ever sleep the same at night after writing something like that In these situations, you likely know your hardware and know your compiler, so you can actually provide an answer for 4 of the questions. The last one is a situation where someone should tell you not to get cute in the code review. I wrote C in telecom and finance and in both places we enforced a rule: when you define a structure, p…

> In some of our code, we would test the size of various types and structures on startup

This is one of the things that C++ has actually improved a lot recently: doing this with static_assert is much nicer in terms of catching problems early... And yes, it's great for long-term maintainability.

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

#135

Post by WC3w6pXxgGd » Sat, Jul 06, 2019, 4:23 AM UTC

No.

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

#136

Post by bzbarsky » Sat, Jul 06, 2019, 4:23 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.

Or doing the whole thing mod 2.

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

#137

Post by beached_whale » Sat, Jul 06, 2019, 4:26 AM UTC

The third one has another implementation defined aspect. We do not know the value of a space ' ', in ascii it is 0x20(32) but that depends on the system, in EBCDIC it is 0x40(64).

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

#138

Post by unwind » Sat, Jul 06, 2019, 4:28 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…

I hope I'm being on topic and reasonable to point out that the result of the sizeof operator is in "number of chars", not bits.

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

#139

Post by [deleted] » Sat, Jul 06, 2019, 4:34 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."

[deleted]

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

#140

Post by will4274 » Sat, Jul 06, 2019, 4:35 AM UTC

Dylan16807 wrote: post #43

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…

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

No, it isn't. The correct answer to #2 is "According to the standard, the result is implementation defined, but on my target platform, 0". "I don't know" is the wrong answer.