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

321–330 of 344 posts

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

#321

Post by ineedasername »

Dylan16807 wrote: post #294
ineedasername wrote: post #279

Earlier quoted context omitted.

You don't think the claim is justified because some might say otherwise. Some is irrelevant. Some might say lots of mutually exclusive interpretations. It's the author's intent that matters, and the context of the Author's post indicates the some interpretation isn't the author's intent. His post begins with the question "So you think you know C?". He then goes on to present a test that is, by his own words, intended…

Showing how people misunderstand the intricacies of C is much closer to "C is confusing" than "distinguishing who is honest about their limitations".

And yet its not confusing. Given the confines of any particular implementation and compiler the behavior can be known without confusion. The author never directly mentions or implies that their intent is to convey that C in confusing. Quite the contrary, they indicate their intent is to demonstrate that certain segments of people who believe they know C don't in fact understand its intricacies.

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

#322

Post by Dylan16807 »

ineedasername wrote: post #321
Dylan16807 wrote: post #294

Earlier quoted context omitted.

Showing how people misunderstand the intricacies of C is much closer to "C is confusing" than "distinguishing who is honest about their limitations".

And yet its not confusing. Given the confines of any particular implementation and compiler the behavior can be known without confusion. The author never directly mentions or implies that their intent is to convey that C in confusing. Quite the contrary, they indicate their intent is to demonstrate that certain segments of people who believe they know C don't in fact understand its intricacies.

> Given the confines of any particular implementation and compiler the behavior can be known without confusion.

Only through extreme levels of compiler code inspection, as it can vary based on optimization heuristics.

> Quite the contrary, they indicate their intent is to demonstrate that certain segments of people who believe they know C don't in fact understand its intricacies.

Demonstrating that people don't know C is subtly different from an intent of testing whether people know C. The point being made is about C itself.

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

#323

Post by Thorrez »

ineedasername wrote: post #320
Thorrez wrote: post #313

Earlier quoted context omitted.

If what "some" might say about what the author intends is irrelevant, then what you say about what the author intends is also irrelevant, because you are just some person (unless you're the author). My point was why should I trust your interpretation of what the author intends more than anyone else's. >"So you think you know C?" That goes along with the interpretation that the point is to illustrate C is confusing. I…

My interpretation is based directly on what the author states. Your "some" is based on a vague aggregate group whose interpretations, in aggregate, would be diverse and often contradictory and mutually exclusive. Personally, I trust the explicit an implied interpretation of the author's direct statements than you mere speculation as to what others might interpret.

If you don't like "some" then replace it with me. I interpret it as the author saying C is confusing.

My interpretation is also based on what the author states, fairly explicitly. And I don't think there's anything that explicitly contradicts my interpretation.

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

#324

Post by prirun »

Gene_Parmesan wrote: post #310
akavi wrote: post #245

Earlier quoted context omitted.

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

For those who may have trouble with loops, take heart: after 45 years of non-stop programming, often 10+ hours a day, I still find myself sometimes doing mental loop simulations with small (few element) data to make sure a loop is correct.

It's usually much easier to take extra time to make sure it's right than to debug it later.

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

#325

Post by rramadass »

mhh__ wrote: post #306
rramadass wrote: post #272

Earlier quoted context omitted.

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?

The OpenSSL "Heartbleed" bug that you bring-up is not related to inherent failures of the C language but something else. Just as an aside, i actually have some background in implementation of security protocols (specifically IPSec framework) and FIPS certification for a cryptographic algorithms library, though by no means am i an expert. In the security community many people believe that "Heartbleed" was an intentional plant. See https://www.smh.com.au/technology/man-who-introduced-serious... OpenSSL is such a heavily used and vetted piece of software that the probability of this being an "accidental bug" is very very low and my money is on it having been deliberately inserted i.e. deliberately used C language features towards a nefarious goal. So this is not a good example to bring up.

Now coming to your other point, in today's environment, it is true that you do not lose much for the most part when using a safer language because somebody else has done the dirty work in the implementation of the corresponding language's runtimes, compilers, libraries and ABIs. Without the latter you cannot have the former. After all at some point you have to move out of the cocoon provided by the language and meet real hardware (a good example is bare-metal programming on MCUs). And that is where C is needed and any challengers have to provide exactly similar "ugly, dangerous and unsafe" features if they want to dethrone the champ.

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

#326

Post by todd8 »

dahart wrote: post #300
GorgeRonde wrote: post #270

Went to an IRC chat room when I was learning C in school. Asked if you could return a pointer to something that lives on the stack. Was talked down by an all-knowing dude telling me to go read K&R again. Proceeded to write a code sample [1] that showed it is possible (it's not really stable but works reliably in recursive calls IIRC). I do not like this attitude (then again it was just one random dude). [1] https://w…

> it is possible (it’s not really stable but works reliably in recursive calls IIRC). [...] I do not like this attitude You might want to listen. You’re getting the K&R comment and the downvotes because this does not work, ever. It’s a really, really bad idea. In recursive calls, it might not crash right away, but you will have bad data, the memory at the pointer address will have been overwritten by the next stack f…

Yes.

Signal handlers allow C programs to respond to events outside of the normal control flow (see signal.h, etc.). This means that once a function, say fnc1, has returned, the memory on the stack that was used by fnc1 can end up being reused at any point in time. A signal, perhaps generated completely asynchronous to the program itself by a different process, causes a stack frame to be allocated (possibly on top of fnc1’s old stack frame) for use by the corresponding signal handler. This could happen at any time, even before fnc1’s caller gets a chance to use the pointer returned by fnc1.

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

#327

Post by Dylan16807 »

raviolo wrote: post #287
detaro wrote: post #286

Earlier quoted context omitted.

There's explanations at the bottom after you click the button.

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?

Imagine a dumb piece of hardware storing your variables. Two pieces of a statement try to do conflicting things to the same variable at the same time. This can cause the data to get corrupted, or the entire chip to have a fault. The C standard allows an implementation like this.

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

#328

Post by saagarjha »

pjmlp wrote: post #230
saagarjha wrote: post #197

Earlier quoted context omitted.

I believe DriverKit is still C++.

Just some parts of it. Some device classes (not to mix with OOP ones) can only be programmed with C++, while others can be developed in any compiled language able to link to the OS APIs. There is a WWDC session on it.

I watched it, and they're pretty clear that driver extensions (using DriverKit, like I mentioned) must be written in C or C++. System extensions can use any language.

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

#329

Post by pjmlp »

saagarjha wrote: post #328
pjmlp wrote: post #230

Earlier quoted context omitted.

Just some parts of it. Some device classes (not to mix with OOP ones) can only be programmed with C++, while others can be developed in any compiled language able to link to the OS APIs. There is a WWDC session on it.

I watched it, and they're pretty clear that driver extensions (using DriverKit, like I mentioned) must be written in C or C++. System extensions can use any language.

I was thinking about whole driver feature set, so got it wrong.

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

#330

Post by GorgeRonde »

todd8 wrote: post #326
dahart wrote: post #300

Earlier quoted context omitted.

> it is possible (it’s not really stable but works reliably in recursive calls IIRC). [...] I do not like this attitude You might want to listen. You’re getting the K&R comment and the downvotes because this does not work, ever. It’s a really, really bad idea. In recursive calls, it might not crash right away, but you will have bad data, the memory at the pointer address will have been overwritten by the next stack f…

Yes. Signal handlers allow C programs to respond to events outside of the normal control flow (see signal.h, etc.). This means that once a function, say fnc1, has returned, the memory on the stack that was used by fnc1 can end up being reused at any point in time. A signal, perhaps generated completely asynchronous to the program itself by a different process, causes a stack frame to be allocated (possibly on top of…

Thanks, that was interesting.
Post reply on HN