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

301–310 of 344 posts

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

#301

Post by akavi »

naasking wrote: post #296
akavi wrote: post #292

Earlier quoted context omitted.

“#zip”? Or maybe I’m misunderstanding the use case?

Which only works if the sequences align perfectly. Handling misaligned collections is more awkward with functional constructs. Functional graph programming is also still a bit of an open problem. There are awkward scenarios in both cases.

Ah, I see what you mean. Yeah, that’s always awkward

Not sure how you deal with that with for loops either. Increment the iteration var in the body of the loop? (Seems scary to me, but like I said, I’ve got terrible intuition with them)

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

#302

Post by dahart »

noahmorrison wrote: post #299
dahart wrote: post #295

> And at this point, I only have to apologize. The test is clearly provocative and may even be a little offensive. I’m sorry if it causes any aggravation. [...] It was a research project in nuclear power plant automation, where absolutely no underspecification was tolerable. I appreciate the apology here, and I can totally understand the concern about the spec in a safety critical environment. Still, all questions on…

Still, I’d be interested to hear about a compiler that doesn’t return 1 gcc (Ubuntu 8.3.0-6ubuntu1~18.10.1) 8.3.0 returns 2 (executes from left to right... at least the first time I ran it).

Wow, you’re right. Me too on ubu 16. Okay, I guess it’s not about pre or post increment. Maybe I should read the spec... ;) And good reason not to do this in code!

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

#303

Post by Leherenn »

seba_dos1 wrote: post #254
ogoffart wrote: post #229

Earlier quoted context omitted.

You are absolutely right, but my point is that when you do modern C++, in the application code, it is very unlikely that you need to use reinterpret_cast in your code, and therefore you don't need to know all the subtlety about it. So despite C++ being more complex than C, if you limit yourself to some practical subset, it is actually easier than C.

Same can be (and has been) said about JavaScript. Or C. Or any language with any kind of issues. And it doesn't work in practice.

I think it does sometimes? At least for enterprise software.

We use both C and C++ embedded as well as C++/Qt for the desktop control system, and we have no issue keeping to a sane subset of C++.

There are clearly defined rules and code review does the remaining enforcement. And it's not even hard or time consuming as everyone is pretty much aligned and every small issue can be easily resolved with a quick chat.

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

#304

Post by kurlberg »

usr1106 wrote: post #21

I failed on one, number 4. I bravely assumed 16 bit integers cannot exist. Can anyone name a concrete platform/compiler where int is/was 16 bit. Or is this just a theoretical option left open by the spec?

My amiga c compiler (aztex manx) allowed either 16 or 32 bit ints. All/most systems libraries used 32 bit parameters, despite this I insisted on the 16 bit version "for performance". In hindsight this was sort of insane: one missing L (say in "1L" for casting to long) meant a not so quick floppy disk reboot). :-)

Anyhow, for a computer with 16 bit wide data bus, having 16 bit ints might be justified by performance (and/or reducing memory usage.)

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

#305

Post by aey »

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…

> I feel like the questionnaire piss off people who really knows C.

I hated this test. I’ve spent 12 years working on C targeting various flavors of arm and x86.

Just because the behavior is undefined when compiled without warnings and run on a Soviet water integrator doesn’t mean the language is undefined for the 99.995% of the industry uses.

Behavior of c89 or later with -Wall -Werror on modern clang, gcc, icc, visual studio, is well understood on arm, x86, mips, risc, ppc, Cortex-m and just about every other hardware architecture.

But, C is a pia, and I’ve been using rust instead :)

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

#306

Post by mhh__ »

rramadass wrote: post #272
mhh__ wrote: post #228

Earlier quoted context omitted.

I'm almost not. I made the point because this level of ambiguity and "do it yourself" is consistent throughout the language. I know why we still use C, but the use of C is inherently prone to security problems. C does not provide bounds checking by default, so it can be forgotten (Heartbleed) and the lack of either static checking, RAII or garbage collection (Not as a library e.g. Boehm) makes memory corruption all b…

People are forgetting that it is the very "looseness" of C that is responsible for its great success. The sheer volume of code in C (specifically, any number of complex and critical software) is a testament to that. People keep parroting the same old tired tropes about C without reflection and thought. All the problems, both real and imaginary, in the language have been worked through/around since the beginning by si…

This is fine for your or my software but the risk of these bugs no matter how rare is too great for mass deployed code in something similar to OpenSSL.

Any good alternative still allows you manipulate raw memory, but provide a safe alternative which makes it much harder to fuck up.

What power do I actually lose by using a safer language?

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

#307

Post by dahart »

JKCalhoun wrote: post #290
raviolo wrote: post #287

Earlier quoted context omitted.

I read it but I still don’t understand. Isn’t it 0 + 2 vs 1 + 1? How would it produce something other than 2?

How do you get 0 + 2? I could imagine the post-increment happening after the sum: giving 0 + 1…

That’s what I imagined, and what I get with Cygwin gcc, the result is 1. I thought that the post-increment was supposed to always only happen after the “statement”, but I was wrong. Other compilers, like gcc on Ubuntu return 2.

This looks like a good explanation of why both are correct and why it’s confusing: https://stackoverflow.com/a/4445841

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

#308

Post by userbinator »

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…

It's easy to see why compiler developers added these optimizations: someone filed a bug saying "hey, why is my loop full of movsx", and the developers fixed the problem.

"fixed" by breaking other expectations. Regardless of what the spec says, that's still a stupid way to do things. There's a child comment below which examines this case in detail; and the real solution is to make the analysis better, not use UB as a catch-all excuse.

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

#309

Post by Gene_Parmesan »

dahart wrote: post #276
bufferoverflow wrote: post #209

Earlier quoted context omitted.

Though different people consider different things simple. To one a loop is fine, to another a map is a better choice.

> to another a map is a better choice. Are you thinking more of JS or another functional scripting language than C/C++? C doesn’t have map, so it’s not an option, and in C++ it’s called something else. In JS, I so wish that I could switch to functional constructs like map permanently, but map and foreach are much slower than loops, an order of magnitude or more for tight loops. I’m still forced to use loops in perfor…

> order of magnitude or more for tight loops

I just learned this about JS's map/foreach a few weeks ago. I didn't think it was possible to be more disappointed by JS than I already was, but somehow I managed it.

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

#310

Post by Gene_Parmesan »

akavi wrote: post #245
WalterBright wrote: post #213

Earlier quoted context omitted.

map/filter/reduce is simpler, but it takes some getting used to. Loops have worn a deep rut in my brain.

As someone who was introduced to programming via map/filter/reduce, for loops are incredibly more complicated. I don’t think I’ve ever written one correctly on first try.

> I don’t think I’ve ever written one correctly on first try.

Please don't take offense, but this is odd to me. I honestly severely doubt I am some sort of programming super genius, but I have never had any issues setting looping logic correctly. (I took four years to teach myself programming & CS and now I've been at my first professional dev job for ~6 months.) None of my colleagues seem to have such issues either. What are you experiencing trouble with most? Off-by-one?

Post reply on HN