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

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

#331

Post by GorgeRonde » Sun, Jul 07, 2019, 10:30 AM UTC

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…

Listening to what ? To the dude that tells me that's not possible and proceeds to dump a big pile of authority on top of my head or to my own experiment that tells me another story ?

I would have preferred to be told:

- yes and no. You'll get warnings if you try to return a pointer to a local, however, doing this and that, you can manage to do it.

- but once you have achieved that, the result will be dependent on the way the stack is handled (not really in your control). You'll feel some comfort doing this in recursive calls, however beware of signal.h.

But this isn't the answer I received. I guess C programmers do not know the difference between what you can do (however risky) and what you shouldn't do. Also when someone asks such "weird" questions, do not assume he's a beginner with no notion of what constructs he can handle safely, maybe he's someone trying to find the limits of C – and once these limits are identified it can be a good conversation starter about C's internal and the way various compilers differ.

Edit: also downvotes on HN are not like downvotes on Reddit: there's actually a limit (-2 ?). Below this the comment disappears. Conclusion: only downvote when the comment engages in antisocial behavior (not respecting the rules or common human decency, etc ...), not when you disagree with it. I always upvote an unfairly downvoted comment for these reasons.

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

#332

Post by taejo » Sun, Jul 07, 2019, 11:34 AM UTC

WalterBright wrote: post #314

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've used loops so much I don't even see the loop anymore as a collection of constructs, I see it as a single thing. There are a lot of easy mistakes to make with loops, but I don't make them anymore (of course, by writing that, I will make one!). For example: #include #include typedef long T; bool find(T *array, size_t dim, T t) { int i; for (i = 0; i There are 5 errors in that example.

Is the fifth error that there are only four errors?

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

#333

Post by xondono » Sun, Jul 07, 2019, 1:01 PM UTC

jason0597 wrote: post #315

xondono wrote: post #223

Earlier quoted context omitted.

Is still a little early, but as someone who works at the bare metal level, Rust shows early promise. The features required are still unstable (as in not in the stable version of the compiler), but it’s getting there, and doing it fast. In any case, firmware behaves a lot like banking software, language change will take time

Cargo feels like too bloated to me for it to be something suitable for something low level like embedded. Unless the rust team can make it more appealing to use the language without cargo, I don't think there's much future.

In bare metal systems, cargo would run on the developers host system, so that should not be an issue.

Also, most toolchains of the sector are way more complex to maintain and way more bloated.

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

#334

Post by will4274 » Sun, Jul 07, 2019, 3:00 PM UTC

zAy0LfpBZLC8mAC wrote: post #219

will4274 wrote: post #140

Earlier quoted context omitted.

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.

The C specification does not say that undefined behaviour must give a deterministic result on a given platform. All you can say is "this one time I compiled and then ran this code, it gave 0". There is no requirement that the code compiles at all, nor that the same compiler on the same platform produces the same binary on every run, nor that the resulting binary produces the same result on every run, nor that the bin…

I'm well aware of what undefined behavior is. I still know it's undefined behavior and can read my compiler manual to answer the question of how the code behaves. "I don't know" is simply wrong.

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

#335

Post by dahart » Sun, Jul 07, 2019, 3:02 PM UTC

GorgeRonde wrote: post #331

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…

Listening to what ? To the dude that tells me that's not possible and proceeds to dump a big pile of authority on top of my head or to my own experiment that tells me another story ? I would have preferred to be told: - yes and no. You'll get warnings if you try to return a pointer to a local, however, doing this and that, you can manage to do it. - but once you have achieved that, the result will be dependent on the…

I was trying to help by explaining it, instead of saying go read K&R, but I don’t get the feeling you really heard or understood me. There is no other story. There is no yes and no. There is only no. You cannot manage to do it. It does not work to return local memory from a function, ever, period. Once you return, it is 100% unsafe to try to use the memory from your previous stack. There is absolute zero comfort in recursive calls.

You are mistaking some luck in having it not crash once for thinking that it’s okay in some situations. It’s not okay under any circumstances. That’s what makes this even more dangerous. Your program could crash at any time. It might run a thousand times and then suddenly start crashing. It might always run for you, and then crash on other people. But just because it runs once without crashing doesn’t mean it’s working.

A signal is not the only way your function’s stack can get stomped on the very next instruction after you return. Other processes and other threads can do it, the memory system can relocate your program or another one into your previous memory space. Recursive calls are guaranteed to stomp on previous stack frames when your recursion depth decreases and then increases, the previous stack will be overwritten.

Returning a pointer to a local stack frame is always incorrect. It’s not risky, it’s wrong.

BTW: you have the ability to see comments below the downvote limit, go to your profile settings and turn on showdead.

I didn’t downvote you, if that’s why you were trying to explain voting behavior to me, but you will find on HN that downvotes and upvotes both happen for a wide variety of reasons, and are not limited to either whether people agree, nor whether the comments are polite. Downvotes are often cast for comments that break site guidelines, for example just failing to assume good faith can get you downvoted. So can making blanket generalizations about a group of people, like the above “I guess C programmers do not know the difference...”. See the comments section here: https://news.ycombinator.com/newsguidelines.html

I sometimes upvote what appear to be unfairly downvoted comments to me. I usually upvote people who read and respond to me, regardless of whether I agree with them.

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

#336

Post by GorgeRonde » Sun, Jul 07, 2019, 5:38 PM UTC

dahart wrote: post #335

GorgeRonde wrote: post #331

Earlier quoted context omitted.

Listening to what ? To the dude that tells me that's not possible and proceeds to dump a big pile of authority on top of my head or to my own experiment that tells me another story ? I would have preferred to be told: - yes and no. You'll get warnings if you try to return a pointer to a local, however, doing this and that, you can manage to do it. - but once you have achieved that, the result will be dependent on the…

I was trying to help by explaining it, instead of saying go read K&R, but I don’t get the feeling you really heard or understood me. There is no other story. There is no yes and no. There is only no. You cannot manage to do it. It does not work to return local memory from a function, ever, period. Once you return, it is 100% unsafe to try to use the memory from your previous stack. There is absolute zero comfort in r…

    - Java: no
    - Ruby: no
    - PHP:  no
    - C:    yes and no

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

#337

Post by ineedasername » Sun, Jul 07, 2019, 6:26 PM UTC

Thorrez wrote: post #323

ineedasername wrote: post #320

Earlier quoted context omitted.

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.

You say it's confusing because the author says it's not simple. The same might be said of any language. Or of any learning specialty at all. It's not synonymous with confusing. You're severely stretching the meaning of the author's words when you say the author's point was to say that C is confusing. It's what you infer because you were confused, which points to this being personal to you, not the general intent of the author.

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

#338

Post by mikeash » Sun, Jul 07, 2019, 8:50 PM UTC

owl57 wrote: post #212

saagarjha wrote: post #101

Earlier quoted context omitted.

Or your standards conforming but mischievous compiler does something nondeterministic ;)

1) This made me curious. Are any of the compilers in real use nondeterministic? 2) Probably that's not needed? A normal optimizing compiler just inlines the function somewhere new — and boom? Then again, can that really happen with practical contemporary compilers and this exact statement?

Most compilers are nondeterministic in small ways. For example, it's common to use hash tables that are keyed by pointer address and then iterate over the entries in storage order, so the order in which certain things are emitted will change from run to run. This is why "deterministic builds" are such a big deal, and not just an obvious thing that you get for free.

I don't know what the chances are that such a thing could ever translate into good assembly being emitted in one run and bad assembly being emitted in the next.

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

#339

Post by dahart » Sun, Jul 07, 2019, 11:43 PM UTC

GorgeRonde wrote: post #336

dahart wrote: post #335

Earlier quoted context omitted.

I was trying to help by explaining it, instead of saying go read K&R, but I don’t get the feeling you really heard or understood me. There is no other story. There is no yes and no. There is only no. You cannot manage to do it. It does not work to return local memory from a function, ever, period. Once you return, it is 100% unsafe to try to use the memory from your previous stack. There is absolute zero comfort in r…

- Java: no - Ruby: no - PHP: no - C: yes and no

?? I don’t understand what you mean. Those other languages don’t have pointers, they only have references, but what do they have to do with this?

Why do you still think there’s some yes in C? It’s not making sense yet that your memory is gone after you return? Returning a pointer to a local variable is exactly the same as calling delete or free on a pointer and then reading from it. You officially don’t own the memory after a return statement, so if you try to use it, then what happens is indeterminate. Again, since it doesn’t seem to be sinking in: it is always wrong to return a pointer to local memory. But, if you really really don’t want to listen, and you’re sure it works sometimes, then I say go for it!

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

#340

Post by zAy0LfpBZLC8mAC » Mon, Jul 08, 2019, 12:55 AM UTC

will4274 wrote: post #334

zAy0LfpBZLC8mAC wrote: post #219

Earlier quoted context omitted.

The C specification does not say that undefined behaviour must give a deterministic result on a given platform. All you can say is "this one time I compiled and then ran this code, it gave 0". There is no requirement that the code compiles at all, nor that the same compiler on the same platform produces the same binary on every run, nor that the resulting binary produces the same result on every run, nor that the bin…

I'm well aware of what undefined behavior is. I still know it's undefined behavior and can read my compiler manual to answer the question of how the code behaves. "I don't know" is simply wrong.

> and can read my compiler manual to answer the question of how the code behaves.

Which is both not true (because the compiler manual usually won't define undefined behaviour) and irrelevant (because the questions were about C, not about a compiler).