C++ null runtime checking

JonB

Inspired by thinking about https://forum.qt.io/topic/145516/error-handling-linux-qt-5-15.

Sure, it's the programmer's responsibility not to deference "null" pointer. C++ doesn't "nanny", and it's efficient so it's not going to insert a pointer check each time.

I get it. But why doesn't it (g++/gcc, from what I can see, unless someone knows otherwise) just offer a compiler code generation option which allows coder to switch it on for debugging if that's what they want to do? Surely it's like one "JSR" instruction per pointer deref instruction, that wouldn't be much work to add would it? Not sure, but have a feeling an earlier MSVC might have had an option for this.

JoeCFD

@JonB https://doc.qt.io/qt-6/qtlogging.html can be used for Qt code.
You can add a logging mechanism and turn it on/off. This is very useful because sometimes it is very hard to use debugger to go through code when threads are heavily used.
For example in my code in this scenario

if ( nullptr == tt ) {
    QLoggerCritical( ui ) <<  Q_FUNC_INFO << "Empty pointer";
}
*tt  = 123;

Q_FUNC_INFO tells func name+class name and location.

ui is set on(true) in a file .config/myproject/qtlogging.ini. Different tags can be applied for different modules.

[Rules]
project.ui.*=true /* false will ignore the check */

Similar thing can be done for pure C++ code as well.

Chris Kawa

I don't see a point? Injecting an exception handling code into every pointer deref would pretty much prevent most of the optimizations a compiler can do and would make the app run super slow. If it's just for debugging then... run it under a debugger and get a nice breakpoint and a juicy callstack exactly where it crashes. What would you do with that exception anyway? Access Violation is a system level fault. There's no recovery from it and anything you do in the catch block is just undefined behavior and playing with fire. Also modifying code (even by the compiler) that you're trying to debug makes you no longer debug the code you want to debug. You're debugging something else.

@JoeCFD I think you missed the point. Logging before you access a null pointer is not the same as catching a use of null pointer when it happens. Your logging code is actually valid C++ up until the assignment. The question was about a non-conforming compiler extension that would let you handle what is undefined behavior in the standard - catching the system level exception of access violation.

JonB

@JoeCFD
I'm asking about a compiler option to generate an instruction to check every pointer access for 0. Not me coding every pointer access I make. OIC, @Chris-Kawa has written this.

Chris, yes, I suppose it wouldn't be super-helpful. I did only mean for developing/debugging. You might as well run it under debugger anyway. Just would save having to tell people to do it and what the stack trace pane is :)

Chris Kawa

@JonB "Run it under a debugger" is easier than "Here's how you pass some magic flags to your particular compiler on your particular system with your particular build system and using your particular IDE, so you can then guess where to write some native, non conformant exception handling code that you probably never did in your life up to that point, and then spend another back-and-forth explaining why they can't do a particular thing in the catch block. And what's up with that try and __try thing? Why doesn't it compile on my particular setup?"

Nah, just use the debugger. That's what it's for. If someone's a novice programmer they'll need to learn it sooner rather than later anyway, so might as well use the opportunity.

Kent-Dorfman

@JonB said in C++ null runtime checking:

But why doesn't it (g++/gcc, from what I can see, unless someone knows otherwise) just offer a compiler code generation option which allows coder to switch it on for debugging if that's what they want to do?

Because it encourages bad programming. Null pointer exceptions are hardware traps, not software defined exceptions, as the other exception categories are. If you "allow" a null pointer trap to occur then you didn't do your due diligence in checking bounds for your operation.

Going down the path of an automatic check is one step closer to doing runtime bounds checks on arrays, which are not part of the C/C++ legacy. If you want bounds check safety then that's why we have the STL container operations.

JonB

@Kent-Dorfman said in C++ null runtime checking:

Because it encourages bad programming.

You are harsh in your judgments! Using a debugger at all can also "encourage bad programming" in these terms :)

Kent-Dorfman

@JonB
I guess that could seem harsh, but people are generally lazy and only rise to the expectations set for them. If you allow null pointer exceptions to be implicitly handled then folks will overuse that "feature". Think of it this way. Unless forced to do so by team standards, would you use -Wall -pedantic or allow less serious violations to go unchecked?

My past few years of AUTOSAR/MISRA are making me a lot less tolerant of things that come across as questionable.

ie debuggers...how much time is spent architecting and peer reviewing in the hopes of avoiding the necessity to use the debugger in the first place? or is runtime debugging an expected and necessary part of the process?

Of course these grand ideals only apply to code destined for release. I don't wish to dictate folks process or methodology, as long as when it's presented as "user ready" it's gone thru a QA process that encourages the above.

JonB

@Kent-Dorfman said in C++ null runtime checking:

Of course these grand ideals only apply to code destined for release.

I always said this was about enabling only for debug. But I agree it doesn't give me much if I have a debugger available.