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 frame that’s placed there.

Don’t ever return pointers to local memory because the memory is “gone” and unsafe to use the moment your function returns. Even if you try it and think it works, it can and probably will crash or run incorrectly in any other scenario - different person, different computer, different compiler, different day...

Your comments about getting a warning and ‘However if you wrap the local’s address... it “works”’ should be clues. The warning is the compiler telling you not to do it. The workaround doesn’t work, it only compiles. By using aliasing, you’re only tricking the compiler into not warning you, but the warning is there for a reason.

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.

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://hackertimes.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.

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

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!

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.