4 ms·
Yes, but null pointers are so pervasive in C code that we really can't afford to put assertions everywhere. It's often better to let the app crash on violations
by hathawsh 4mo ago
Yes, but null pointers are so pervasive in C code that we really can't afford to put assertions everywhere. It's often better to let the app crash on violations.
- dwattttt 4mo agoAn assertion is an app crashing on a violation. The problem is when it's not guaranteed to crash, and instead does something very wrong.
- jstimpfle 4mo agoA bug is a bug even when it doesn't clearly manifest itself 100% of the time, and furthermore it is pretty much guaranteed that NULL dereference crashes with segfault in practice, only not for the people playing theoretic games whose essence of life is finding gotchas where it maybe isn't so and then feeling smarter than everyone else. But it's >> 99.9% true that this will just crash even though it's acshually UB, nasal demons and so forth. Now raise this << 0.1% likelihood that it isn't true on some system with some compiler and build flags, to the power of the number of distinct deployed configurations out there, and you get the result which is the correct engineering decision of just moving on instead of spending your life filling straightforward code with pointless boilerplate assertions. NB it can make sense to assert nonnull when the condition won't be tested on all code paths or the intention is otherwise not super obvious.
- Dylan16807 4mo agoI don't want to nitpick people often but your use of division sign to mean percent is really throwing me off.
- jstimpfle 4mo agoThanks for letting me know, nitpick appreciated. Typing on my phone.
- lmm 4mo ago> it's >> 99.9% true that this will just crash even though it's acshually UB, nasal demons and so forth. Is it though? Linux saw enough bugs from that kind of issue that they now build with -fno-delete-null-pointer-checks and accept the (supposed) performance penalty.
- uecker 4mo agoThe kernel is perhaps bit special. In the past they had bugs such as first derferencing and then checking for null and weird possibilities to map the zero page. But today I am not convinced this is really needed. In general on a system where you trap when accessing the zero page, this optimization should be safe and a null pointer dereferences should (safely) trap.
- lmm 4mo ago> In general on a system where you trap when accessing the zero page, this optimization should be safe and a null pointer dereferences should (safely) trap. If you mean that C compiler writers "should" prioritise sanity over high scores on microbenchmarks, then I agree. However in practice they do not and this optimization is not remotely safe.
- uecker 4mo agoDo you have any evidence for this? On GCC it should be safe. (EDIT: what is not safe is indexing into a null pointer. For this you need to be safe you need -fsanitize=null)
- lmm 4mo agoI don't understand your comment - dereferencing a null pointer is unsafe, in the sense that it does not reliably crash but may do other things, as we saw in the kernel case we're talking about. Yes that particular case was only exploitable if you mapped the zero page, but given how all-bets-are-off a situation it created (where extremely experienced programmers thought they knew what the code did, thought it was safe, and were wrong), I would not want to count on all cases not being exploitable without mapping the zero page.
- asveikau 4mo agoAn assert is not guaranteed to terminate the process. In C, the most common implementation choice is to completely omit the check if you're not building in debug mode.