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

Developers using the open source LibEtPan library in their email agents need to patch against a null-dereference vulnerability. Among other things, the library is used in MailCore and MailCore 2, which provide Objective C APIs to the IMAP, POP and SMTP protocols. The bug is in LibEtPan's MIME handling in version 1.7.2 and …

  1. Lee D 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.

    1. the spectacularly refined chap

      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.

  2. Khaptain Silver badge

    Says it all

    if (!ptr)

POST COMMENT House rules

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

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2019