Examined own navel, found lint. Must search all navels. Yum yum!

Recently, there was an issue at a customer site which was ultimately caused by silent truncation of a 64-bit value into a 32-bit structure member. It took a few days for the engineers concerned to spot that this was in fact the issue given the symptoms (these are really hard to spot by code inspection), but I wondered why lint hadn’t warned us about it, since it knows how to detect this class of problem.

It turned out that lint was trying to tell us, but that class of problem had been suppressed in the Makefile with an -erroff directive, so we had told it not to. Removing this revealed several other places where potential issues could arise due to this type of truncation (which were all checked and thankfully could not produce any ill effects).

I remember reading something years ago when at University – “The Ten Commandments of C Programming” which contained the entry “Thou shalt produce lint-clean code at all times”. It generated a snigger back then, but looking back with the experience of the recent outage, it starts to look a little less ridiculous.

Lint may be viewed as an old and outdated tool now, with many other static source anlysers available, but if it’s trying to tell us useful stuff, we should really listen to it. In 2015, I started fitting lint to most of the source for my own OS “SpecOS”, and a few potential bugs got shaken out (which is great news, given how difficult some of them would have been to diagnose after the damage had been done!).

Needless to say I’m currently combing through the core OS source to both increase lint coverage, and highlight any potentially bad or dangerous code along the way. All of this aims to make Solaris more stable, robust, and consistent, without nasty bugs around the corner waiting to bite us that we could have discovered first using lint.

Yes, we use other static checkers on the source too, but due to the way our build process works, lint is the most in-yer-face one when something is wrong, so it forms a good first-line defence against simple but hard-to-spot coding errors.