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

141–150 of 344 posts

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

#141

Post by unwind »

bzbarsky wrote: post #134
OldHand2018 wrote: post #77

Earlier quoted context omitted.

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

C has had standardized static assert since the C11 spec was released. See [1] for instance.

[1]: https://stackoverflow.com/a/7287341

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

#142

Post by scarface74 »

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 a Mac program BBEdit that was first written to target 68K 32 bit Macs, then PPC 32 bit Macs, then 32 bit x86 Macs and then 64 bit Macs. Probably within the next 3 years it will target ARM Macs.

The author said he never did a full scale rewrite. He slowly migrated code from one platform to the next.

Today, Apple’s code runs on both ARM and x86 and with Marzipan, as will developers code. True most will be in Objective C, but some low level code is still in C.

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

#143

Post by scarface74 »

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.

I only got two out of five. One so really didn’t know and I remembered enough C to remember sequence points.

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

#144

Post by erik_seaberg »

bzbarsky wrote: post #132
saagarjha wrote: post #109

Earlier quoted context omitted.

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

It's a collective action problem. If we want to give up runtime performance and get stronger guarantees about what code will be understood to mean, we should revise the standard and start using new optimizers that respect it. If every compiler goes its own way, I only benefit from what they already agreed on.

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

#145

Post by AdieuToLogic »

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.

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

This pretty much is the definition of "undefined behaviour" in the context of a standardized language specification.

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

#146

Post by amluto »

AdieuToLogic wrote: post #145
Filligree wrote: post #82

Earlier quoted context omitted.

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

> Compile it, look at the assembly. You can know. The answer will vary from place to place, but it isn't non-existent. This pretty much is the definition of "undefined behaviour" in the context of a standardized language specification.

Whoa there! You mean “unspecified behavior”. int i = [unspecified] means that i has some value, but the spec doesn’t determine the value. Undefined behavior means that all your secrets might be sold to the highest bidder, your centrifuges might explode, and your computer is now full of ransomware.

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

#147

Post by AdieuToLogic »

saagarjha wrote: post #111
kahlonel wrote: post #107

Pro tip: avoid `int`s as much as possible in your C code. Use defined macros instead.

There is a time and place for int32_t.

> There is a time and place for int32_t.

And time_t[0] is not one.

;-)

0 - https://pubs.opengroup.org/onlinepubs/9699919799/functions/t...

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

#149

Post by viraptor »

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 it's still deterministic

That's an assumption though. If it's undefined, the result may even depend on the order of some internal hash table which is affected by other code.

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

#150

Post by AdieuToLogic »

amluto wrote: post #146
AdieuToLogic wrote: post #145

Earlier quoted context omitted.

> Compile it, look at the assembly. You can know. The answer will vary from place to place, but it isn't non-existent. This pretty much is the definition of "undefined behaviour" in the context of a standardized language specification.

Whoa there! You mean “unspecified behavior”. int i = [unspecified] means that i has some value, but the spec doesn’t determine the value. Undefined behavior means that all your secrets might be sold to the highest bidder, your centrifuges might explode, and your computer is now full of ransomware.

> Whoa there! You mean “unspecified behavior”. int i = [unspecified] means that i has some value, but the spec doesn’t determine the value. Undefined behavior means that all your secrets might be sold to the highest bidder, your centrifuges might explode, and your computer is now full of ransomware.

That's only when using Boehm GC[0] in kernel device drivers that self-modify. Or any MSVC binary.

:-D

0 - https://www.hboehm.info/gc/

Post reply on HN