Comments on: Breathalyzer Source Code Analysis

By: Eye, Aye I! « Stack Overflow

Eye, Aye I! « Stack Overflow — Tue, 30 Mar 2010 00:12:29 +0000

[...] the motivation for today’s post, is actually Michael Barr’s latest blog posting concerning analysis of the source code for a breathalyzer. Since I do expert witness work, as well [...]

By: Anonymous

Anonymous — Sat, 09 Jan 2010 12:06:20 +0000

i would love to see an analysis of the speed camera software.michael, any chance you can get hold of that stuff too? how about the radar gun software the police use?

By: Ram C

Ram C — Sun, 22 Nov 2009 14:41:10 +0000

If the device complied with NHTSA’s Model Specifications for Evidential Breath Testers, could this be a case of the standard/process not being stringent enough? The company's marketing folks seem to have quickly exploited the case . From the company website:The Alcotest® 7110 MK III-C is proven evidential breath analyzer. It is the only evidential breath tester on the market whose source code has been reviewed by independent third parties and approved by a Supreme Court decision.

By: Anonymous

Anonymous — Fri, 20 Nov 2009 18:21:31 +0000

"There is no doubt that the Supreme Court should declare this machine to be unreliable"It's tragic to see this in print. It's true that the device has its flaws— as would virtually any embedded system subjected to such scrutiny. But did those flaws actually render the device _unreliable_? Probably not.Individual jurisdictions determine the specifications for breath alcohol analysis devices, and those same jurisdictions conduct continuous testing and calibration to make sure that all the devices in service are meeting those requirements. Thus, "unreliable" devices can— and are— detected and removed from service immediately.Did any of the "flaws" detected by the analysis contribute in any meaningful way to the measurements at issue? That's the critically important question, one that nobody seems to be asking or attempting to answer.

By: PParkBoltFan

PParkBoltFan — Fri, 06 Nov 2009 00:31:49 +0000

I love lint, it is a great tool, however, I not sure I agree completely with the context in which it is being used here. For my projects I configure and restrict the rules of lint in such a way it makes sense for the project. For example, macros and #defines common in embedded apps are never by default included with lint analysis and will causes a lot or warnings. I also have a series of rules I turn off when running lint for embedded apps because compilers limitations and for optimization reasons. 19,000 is not a fair metric to present out of context. That said, I still feel even applying many of my relaxed rules this app would still have a large amount of potential issues. The flawed averaging logic, a common mistake unfortunately, clearly demonstrates a lack of peer review, unit testing, and reasonable system level testing.