Blame Bad Security on Sloppy Programming

From the article in question:

These tools (lint, etc.) have existed for years but are not popular. Why? Because they generate a lot of warnings, and, as countless software engineers have pointed out, it's time-consuming to sift through the spurious warnings looking for the ones that really matter. I've got news for them: there is no such thing as a warning that doesn't matter. That's why it warns you. Anyone who has worked with enough code will tell you that, generally, software that compiles without warnings crashes less often.

And all the programmers said: Right on! I always set my compilers for full warnings, and I recheck and recompile until I get a completely clean build. It's only logical, after all, but logic is too often ignored in production programming, mostly in the interest of speed.

An old friend of mine was fond of telling the marketing droids that their choices were:

  • quality code
  • on time
  • under budget
He'd then ask them to pick two.

ACM Queue has an article that blames security flaws on poor programming, rather than any inherent problems with particular languages. From the article: 'Remember Ada? ... we tried getting everyone to switch to a 'sandboxed' environment with Java in the late 1990s... Java worked so well, Microsoft responded with ActiveX, which bypasses security entirely by making it easy to blame the user for authorizing bad code to execute.'

(link) [Slashdot]

00:00 /Technology | 0 comments | permanent link