Court Orders Breathalyzer Code Opened, Reveals Mess
Death Metal writes with an excerpt from the website of defense attorney Evan Levow: "After two years of attempting to get the computer based source code for the Alcotest 7110 MKIII-C, defense counsel in State v. Chun were successful in obtaining the code, and had it analyzed by Base One Technologies, Inc. By making itself a party to the litigation after the oral arguments in April, Draeger subjected itself to the Supreme Court's directive that Draeger ultimately provide the source code to the defendants' software analysis house, Base One. ... Draeger reviewed the code, as well, through its software house, SysTest Labs, which agreed with Base One, that the patchwork code that makes up the 7110 is not written well, nor is it written to any defined coding standard. SysTest said, 'The Alcotest NJ3.11 source code appears to have evolved over numerous transitions and versioning, which is responsible for cyclomatic complexity.'" Bruce Schneier comments on the same report and neatly summarizes the take-away lesson: "'You can't look at our code because we don't want you to' simply isn't good enough."
Poorly written code is one thing, but does it ultimately work?
not written well, nor is it written to any defined coding standard
Ah, so it's like most of the code in the world.
Because the output is used as evidence in court?
Ok, I'm not happy that some people almost certainly were measured inaccurately by these things. I'm not happy that this company was allowed to pull this kind of shit -- when you do government contracting, the government should own what you do.
However, I am very glad that the precedent has been set.
And I am especially glad that not only is there precedent, but there's a real live example of why we need this stuff to be open.
Don't thank God, thank a doctor!
80% of the code in business fits this description. With 20 year old legacy code written by 50 consultants, then upgraded in India, then ported from one platform to another to another, and a database engine switch or two. Code gets senile. What do they expect? Good thing we're all just commodities... human lego bricks easily replaced with cheaper plastic.
Disconnect your television. Do your own research. Draw your own conclusions. They're probably lying. Don't be a sheep.
Just read Schneier's comments. He cites some of the more important things:
Readings are Not Averaged Correctly: When the software takes a series of readings, it first averages the first two readings. Then, it averages the third reading with the average just computed... There is no comment or note detailing a reason for this calculation, which would cause the first reading to have more weight than successive readings.
That alone should be enough -- the readings are not averaged correctly. But it goes on:
The A/D converters measuring the IR readings and the fuel cell readings can produce values between 0 and 4095. However, the software divides the final average(s) by 256, meaning the final result can only have 16 values to represent the five-volt range (or less), or, represent the range of alcohol readings possible. This is a loss of precision in the data; of a possible twelve bits of information, only four bits are used. Further, because of an attribute in the IR calculations, the result value is further divided in half. This means that only 8 values are possible for the IR detection, and this is compared against the 16 values of the fuel cell.
So we know it's buggy and inaccurate, to a moronic degree. If that wasn't enough:
Catastrophic Error Detection Is Disabled: An interrupt that detects that the microprocessor is trying to execute an illegal instruction is disabled, meaning that the Alcotest software could appear to run correctly while executing wild branches or invalid code for a period of time. Other interrupts ignored are the Computer Operating Property (a watchdog timer), and the Software Interrupt.
So, basically, it's designed to always return some value, even if it's wildly inaccurate, and even if the software is executing garbage at the time.
In other words: It appears to be a very low-level equivalent of Visual Basic's "on error resume next".
Whiskey. Tango. Foxtrot.
So to answer your question: No, it does not work. Even if it did somehow work, there's obviously an unacceptably poor level of quality control here.
Don't thank God, thank a doctor!
This will not stop the state from using this to make a felon of you.
The Navy Motto "IF it ain't broke Fix It" "A day is wasted if you don't learn something new"
If you got your hands on and analyzed the sourcecode to most DVD' players, TV's (Panasonic runs linux!) and other devices that are complex you will discover that in order to ship it earlier the code is an utter mess.
Programmers are not joking when we complain about the "It compiles? Ship it!" statement.
the fault is the Executive staff that refuse to listen to their experts (programmers) and do what they recommend. Instead we get morons that know nothing about programming making unrealistic deadlines and forcing death march coding marathons to give up the mess we have today.
Do not look at laser with remaining good eye.
Did they find any coding bugs,
Yes. RTFA.
2. Readings are Not Averaged Correctly: When the software takes a series of readings, it first averages the first two readings. Then, it averages the third reading with the average just computed.
There you go. It's also inaccurate:
The A/D converters measuring the IR readings and the fuel cell readings can produce values between 0 and 4095. However, the software divides the final average(s) by 256... Further, because of an attribute in the IR calculations, the result value is further divided in half. This means that only 8 values are possible for the IR detection...
And, if there were a catastrophic bug, you wouldn't know it, you'd just keep getting readings:
An interrupt that detects that the microprocessor is trying to execute an illegal instruction is disabled, meaning that the Alcotest software could appear to run correctly while executing wild branches or invalid code for a period of time. Other interrupts ignored are the Computer Operating Property (a watchdog timer), and the Software Interrupt.
This belongs on The Daily WTF.
Don't thank God, thank a doctor!
At a previous job we had to buy a third-party driver for an embedded PCMCIA controller. The software vendor delivered code that (the first time around) produced about 1200 lines of warnings when we compiled it. We queried them about it and they responded that "we don't compile with warning output enabled". Our reply to them was that our coding standard was that the compile would fail on warnings, and we wouldn't accept their code unless they fixed all the warnings... they cleaned up their act, and fixed a couple of previously unresolved problems in the process.
Less is more.
It appears that the NJ Supreme Court wasn't swayed too much by the source code evaluation. They're planning on reinstating the device with only minor modifications.
Xfce: Lighter than some, heavier than others. Just right.
The good: This particular breathalyzer has been proven to be the unreliable POS that it apparently is. This unit, and others like it, will finally start being held to a stronger coding standard.
The bad: every sleezeball, ambulance chasing, "call lee free", douchebag of a lawyer will use this case to attack the credibility of any and all breathalyzers made in the past, present, or future, spreading enough FUD to juries everywhere that an unacceptable number of drunken idiots get the God given right to keep their license until they finally end up killing someone.
As a person, I think groups like MADD spend most of their time trying to scare monger politicians into pushing us as close to prohibition as possible. I believe that alcohol can be used responsibly. But I also know that this case is going to result in DUI's getting overturned for people that damn sure don't deserve it. Borderline cases will get knocked down, cases will get thrown out, and the people that broke the law, that did something wrong, will walk out of a court room 'vindicated.' They didn't do anything wrong when they had six beers and drove home, it was that confounded *machine* that *said* they broke the law. The *machine* was busted, ergo they didn't break the law. In short, this case is going to make a lot of O.J. Simpson's. The jury said they didn't commit a crime, so they didn't. No harm no foul. Technicality? Bah! They're as innocent as the sweet baby Jesus.
I'd like to think things will wash out in the end. This case will probably end up making it harder to get off on this particular technicality in the long term. In the short term? Here come the appeals. Maybe the state is partially at fault for buying shoddy equipment. (Or maybe not. Did they do a code review? Do they have the resources to one? Probably not. Did you do a code review of the 3com switch in your server room? Their selection criteria can certainly be questioned, but it probably doesn't change the fact that someone drank enough to blow a .22 then decided to drive home.)
But in the end, the drunks are still going to be drunks. And tomorrow some of them will probably get to file appeals, and some of the ones that shouldn't be on the road, or even in public, will get to slip out of this brand new loophole. I'm not sure that that deserves a cork-popping celebration.
(and yes: We all handle our booze differently. Arbitrary limits that determine "drunk" may or may not be the answer. Hardcore drunks will keep driving even after losing their license. DUI's are as much moneymakers for the States as speeding tickets. Yadda yadda yadda.)
There are some people that if they don't know, you can't tell 'em.
I work on embedded system stuff every day. At the end of the day, there are NO lint warnings in my code. First, I tend to avoid coding practices and designs that generate lint warnings. By and large, lint warns for a good reason most of the time. Second, in the limited number of situations where lint flags something incorrectly, there are methods for silencing the warnings via special comments. I'm currently working on a 50000 line project, and there are about 70 places in the entire code base were we had to tell lint to ignore a warning. Each warning suppression is documented as to why lint is incorrect.
Lint isn't a perfect tool by any means but in my opinion, anyone developing C code without it is not acting in a professional manner.
OK, LOTS of strange posts from people who claim to have read the article but only see that it's bad code, not actually broken.
Read it again. It's broken from a legal liability and trustworthiness standpoint. It's broken from a precision standpoint. It's broken from an algorithm standpoint. It is not trusworthy, precise, accurate, or correct.
"It is clear that, as submitted, the Alcotest software would not pass development standards and testing for the U.S. Government or Military. It would fail software standards for the Federal Aviation Administration (FAA) and Federal Drug Administration (FDA), as well as commercial standards used in devices for public safety. This means the Alcotest would not be considered for military applications such as analyzing breath alcohol for fighter pilots. If the FAA imposed mandatory alcohol testing for all commercial pilots, the Alcotest would be rejected based upon the FAA safety and software standards."
Nobody in the government or military would be allowed to trust this, if it weren't already in use.
"Results Limited to Small, Discrete Values"
Sixteen values is all it displays! It throws away almost all of the precision of the 12-bit ADC, and reduces it to 4 bits! This is NOT precise enough!
"Catastrophic Error Detection Is Disabled"
"Diagnostics Adjust/Substitute Data Readings"
"Range Limits Are Substituted for Incorrect Average Measurements"
"The software design detects measurement errors, but ignores these errors unless they occur a consecutive total number of times."
It's not correct. It's not accurate. It's not good enough. The odds are VERY good that some people over the limit have gotten off lucky, and also that some people below the limit now have criminal records.
"People who do stupid things with hazardous materials often die." -- Jim Davidson on alt.folklore.urban
With an attitude like that, it's obvious that you have little experience with embedded systems...
:(){