[oraziorillo]

[deprecated post-edit] I guess I used function names beginning with underscore as it didn’t occur to me that it might be un-idiomatic. The intention was to make clear to myself that those functions are private and meant to be only used only in that file. [\deprecated post-edit]

About the second paragraph, first of all, thank you for the suggestions. Can I ask you to elaborate a little on the reasons for your proposals? For instance, even if redundant in some cases, I thought to myself it couldn’t be a bad thing to check for null pointers (though I could improve the error handling itself).

[uecker]

In C, you would typically rely much more on tooling to find bugs (but there are different styles and opinions). Checking for null is not bad, but does not usually add anything. If you de-reference a null pointer, you get a segmentation fault (which is safe) and a debugger will give a nice backtrace. So why catch this by writing additional code if the right tool will give you this automatically? A sanitizer could also add such tests automatically.

For a similar reason, it makes sense to use signed integers. A signed overflow sanitizer will find the overflow bugs or safely terminate the program. Finding unsigned wraparound bugs is much harder.

[oraziorillo]

I see, I agree that especially checking for null really comes to styles and opinions, I still don't have one I can call mine. Thanks for the explanation!

[srean]

I have a different view about checking for NULL.

I would suggest you keep checking for NULLs. It's a good habit to have to watch over details and to remain cognizant of edge cases. There are tools of course but they are neither standard nor as ubiquitous as C.

Sloppiness becomes a habit and creeps into other aspects.

[oraziorillo]

My experience on this project was that the checks proved to be useful way before I could run the program for the first time.

The first version of the code had relatively few null checks. Later I went through and added them consistently at function boundaries, and that process ended up revealing a surprising number of bugs and bad assumptions.

Sanitizers and static analyzers could have surely caught many of these issues later, but adding the checks was a useful way to reason about the code while writing it. It felt less defensive and more proactively preventive.

[srean]

Yeah you can have a lighter work desk that way. You bring in the heavy tools later.

[uecker]

Interestingly, I would see it just the other way round. It is easier for me to reason about the code if it not cluttered with null checks and a null sanitizer is I would see as a very light-weight tool. I may put an assert some once in while if such an assumption needs to be made very explicit.