nav search
Data Center Software Security Transformation DevOps Business Personal Tech Science Emergent Tech Bootnotes BOFH

back to article
Email client lib blown apart by CC: list of death

Silver badge

When writing a library that you intend other people to use to communicate over the public Internet, at least have the courtesy to make some basic tests to check, e.g. that all NULL calls to functions are caught and the like.

People whine about it being C, but this is just sloppy anyway. If you can't spot that NULL can slip through to a function, AND you don't bother to check pointers handed to you for NULL, what the hell kind of other junk has slipped through that you don't care about testing?

Seriously, I have a game that I wrote for myself in C99. Even *that* has NULL checks on every pointer inside every function. I can't say it's "secure" (I wasn't trying for secure) but it's dumb to act on any pointer without checking it's not NULL first. Hell, make a macro or wrapper for your functions if you're that bored of writing things like that. At least you can sort-of forgive "oops, didn't realise the macro would expand that way", even if you are still an idiot - especially if you're writing libraries for public consumption.

9
0

If it's C then things are not always that straightforward. No exception handling complicates how to indicate problems massively, particularly if the target domain of the result covers all values of the return type, and the function simply can't throw an error if its preconditions are satisfied. Constantly checking prerequisites introduces a lot of red tape which obscures the proper operation risking more bugs, and breaks a central principal of design by contract.

Put another way, in C for well written code this often becomes 1) check preconditions 2) call function via needlessly cumbersome invocation 3) function does it's own checks which can't fail due to the checks already done 4) caller now checks result which is also a waste of time because of those same initial checks.

Now for badly written code: what makes you think they'll bother with 4) after skipping step 1)?

By all means drop a few assert()s in there to catch problems in debug trim, they are nowhere near as intrusive and can greatly help self documentation. But adjusting things at the API level and repeatedly testing the same thing wastes time and space and risks introducing more problems by obscuring correct operation.

1
0
Silver badge

Says it all

if (!ptr)

3
0

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

The Register - Independent news and views for the tech community. Part of Situation Publishing