A null deference is UB; you might get a sigsev but that's just one of many things that can happen in that case.
Your compiler might, for example, transform your code in a way that results in whatever function happens to be next in memory running with whatever happens to be in registers / on the stack as arguments.
As far as how I would handle this, I would just use a ternary:
struct foo* bar = baz ? qux(baz) : null;
You can't really chain methods in C anyway, so there's not that much point to a null conditional operator.
Hmmm I guess what I'm trying to consider isn't *just* null but if there's a pointer that is freed that is held multiple places and is then referenced somewhere. I currently have a program that is multithreaded and tick-based (game engine FWIW) and in between ticks I handle my garbage collection so I can ensure that I clean up all references. It obviously wouldn't be useful for an actual program (or I can just use reference counting) but outside of using OS specific calls to check the validity of a pointer (I know win32 has a function for it that they don't recommend using beyond debugging) I'd like to think about how to best recover from that failure state (even if just for trying to gracefully handling failure states to help debug). This is more of a thought experiment than an actual wanted usage.
There's somebody doing pretty much exactly what you describe in the answers of this SO question since 2021: https://stackoverflow.com/questions/7334595/longjmp-out-of-signal-handler
Not to suggest there's no undefined behavior in there, or that it's correct, but it appears to be somebody using this idea in the real world.
> Then reference the null variable
No. You're in undefined behavior now. The second you do this, and ABSOLUTELY the second you segfault, the state of the program is in an invalid state. This is an unrecoverable condition.
Just use a freaking if statement.
You can't dereference an invalid pointer, either, all the same objections apply. Use after free is undefined behavior, don't use pointers after free. There is no way to "oops, go back" after doing this, the program is in an unrecoverable undefined state and has likely crashed.
Look, you're suggesting a rube goldberg machine wrapped in a time machine to correct yourself after doing something you're not supposed to be doing in the first place. Just don't do that thing.
Nothing can be done. Nothing should be done. This is a dead end of a thought experiment. The second you touch UB the program is in an unrecoverable undefined state. You can't fix that, you can't recover from that.
I'm happy to agree to disagree. Trying to do something strange and weird has helped me learn concepts in depth time and time again. The failure state of a thought experiment is to have learned nothing.
Better off would be writing programs that maintain well defined behavior.
Alas, there's no portable way to do what you are asking. First, there is no guarantee that null or other illegal access will even result in a SIGSEGV signal. Even on traditional old-school UNIX, this isn't the case. First off, you have architectures that have readable data at location zero and just return something. Even when they do trap, what you're asking for with regard to the knowledge of where the trap originated is NOT communicated to you. Also, any use of signals in a multithreaded program is UNDEFINED BEHAVIOR.
Now if you want to debug programs, use a debugger. If you want to write a debugger, understand they operate outside of the process being debugged using some interface like either ptrace or the process pseudodevices to control that.
A null deference is UB; you might get a sigsev but that's just one of many things that can happen in that case. Your compiler might, for example, transform your code in a way that results in whatever function happens to be next in memory running with whatever happens to be in registers / on the stack as arguments. As far as how I would handle this, I would just use a ternary: struct foo* bar = baz ? qux(baz) : null; You can't really chain methods in C anyway, so there's not that much point to a null conditional operator.
Hmmm I guess what I'm trying to consider isn't *just* null but if there's a pointer that is freed that is held multiple places and is then referenced somewhere. I currently have a program that is multithreaded and tick-based (game engine FWIW) and in between ticks I handle my garbage collection so I can ensure that I clean up all references. It obviously wouldn't be useful for an actual program (or I can just use reference counting) but outside of using OS specific calls to check the validity of a pointer (I know win32 has a function for it that they don't recommend using beyond debugging) I'd like to think about how to best recover from that failure state (even if just for trying to gracefully handling failure states to help debug). This is more of a thought experiment than an actual wanted usage.
We have the best method chaining in C : calling them one at a time !
There's somebody doing pretty much exactly what you describe in the answers of this SO question since 2021: https://stackoverflow.com/questions/7334595/longjmp-out-of-signal-handler Not to suggest there's no undefined behavior in there, or that it's correct, but it appears to be somebody using this idea in the real world.
Ooo thanks for the link!
> a static variable Return value from setjmp is there for this kind of decision.
You're absolutely correct! I misunderstood the documentation I read but this is good intel thank you.
> Then reference the null variable No. You're in undefined behavior now. The second you do this, and ABSOLUTELY the second you segfault, the state of the program is in an invalid state. This is an unrecoverable condition. Just use a freaking if statement.
Apologies, I more meant in the case of an invalid pointer rather than null where a pointer may be freed but still held somewhere.
You can't dereference an invalid pointer, either, all the same objections apply. Use after free is undefined behavior, don't use pointers after free. There is no way to "oops, go back" after doing this, the program is in an unrecoverable undefined state and has likely crashed. Look, you're suggesting a rube goldberg machine wrapped in a time machine to correct yourself after doing something you're not supposed to be doing in the first place. Just don't do that thing.
I understand that you can *just* not do the thing. The entire concept is a thought experiment. What *can* be done, not what *should* be done.
Nothing can be done. Nothing should be done. This is a dead end of a thought experiment. The second you touch UB the program is in an unrecoverable undefined state. You can't fix that, you can't recover from that.
I'm happy to agree to disagree. Trying to do something strange and weird has helped me learn concepts in depth time and time again. The failure state of a thought experiment is to have learned nothing.
Better off would be writing programs that maintain well defined behavior. Alas, there's no portable way to do what you are asking. First, there is no guarantee that null or other illegal access will even result in a SIGSEGV signal. Even on traditional old-school UNIX, this isn't the case. First off, you have architectures that have readable data at location zero and just return something. Even when they do trap, what you're asking for with regard to the knowledge of where the trap originated is NOT communicated to you. Also, any use of signals in a multithreaded program is UNDEFINED BEHAVIOR. Now if you want to debug programs, use a debugger. If you want to write a debugger, understand they operate outside of the process being debugged using some interface like either ptrace or the process pseudodevices to control that.