Slashdot Log In
Court Orders Breathalyzer Code Opened, Reveals Mess
Posted by
timothy
on Thu May 14, 2009 02:33 PM
from the take-a-sober-look-at-this dept.
from the take-a-sober-look-at-this dept.
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."
Related Stories
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
But does it work? (Score:4, Insightful)
Re:But does it work? (Score:5, Insightful)
Parent
Re:But does it work? (Score:5, Insightful)
I read the report earlier, and there are some very valid issues with the source. The first is that in incorrectly averages readings taken, assigning more weight to the first reading than the subsequent ones. It also has a buffer overflow issue, where an array is being written past its end, and even if this results in an error, it goes unreported.
You would have to be a fricken moron not to have a problem with mis-averaging, however in my experiences with law-people, they can be even worse than PHBs.
Parent
Re:But does it work? (Score:5, Insightful)
Parent
Re:But does it work? (Score:5, Insightful)
Sadly in the majority of cases where evidence based on something like this (DNA, hair analysis, etc) is shown to be based on someone or something that's not good - nothing comes of it. I saw a blurb about a "forensic expert" that would give the prosecution any testimony they wanted. The state he was based in refused to reexamine the cases he was involved in even after he was shown to be a liar.
It's depressing but it's one reason I steer clear of the law as much as I can. As much as we Americans like to think of our legal system as dispensing justice, the sad fact is that it frequently doesn't.
Parent
Re:But does it work? (Score:5, Insightful)
Our legal system and government are about as non-corrupt as Mexico's. Ours just isn't quite as blatant about it.
Parent
Re:But does it work? (Score:5, Insightful)
Parent
Re:But does it work? (Score:5, Interesting)
Since I'm not an American I don't know how a drunk stop works, but here in Denmark, you get to blow on a mobile device, if it shows up as drunk you are taken to the hospital for a blood sample and only that blood sample will be used against you.
Are only the mechanical readings being used in the US?
Parent
Re:But does it work? (Score:5, Informative)
>> assigning more weight to the first reading than the subsequent ones.
It seems to apply more weight to later readings:
where a1=1, b1=2, c1=3, d1=4
(A1+B1+C1+D1)/4 = 2.5 (the correct average)
and
(((((A1+B1)/2)+C1)/2)+D1)/2 = 3.125
Parent
Re:But does it work? (Score:5, Interesting)
This seems to make sense to me. The breathalizer is supposed to measure the blood alcohol content, and this is done by measuring the alcohol content in air expelled by the *lungs* (with a knowlege of partial pressures).
But if you equally weight beginning readings with ending readings, then you can be skewed by the first reading, which comes from the air in the mouth, instead of the lungs (giving low scores for people with time since their last drink, and people high scores with a recent last drink).
I would think that this method would give a more accurate reading by filtering out the readings from 'mouth air' and giving preference to 'lung air'.
But regardles, tests should have been done using both methods, and comparing to blood test to see which returns more consistantly accurate results. I wonder if those tests need to be made public as well.
Parent
Re:But does it work? (Score:5, Insightful)
You can think that you're doing fine because you've gotten good at compensating. For instance, dancers and figure skaters can learn to compensate for inner ear/balance issues from spinning at speeds and duration that would have most people nauseous or throwing up, but the spinning doesn't affect their reflexes. However you don't have to have your cochlear sense of balance feel impaired for intoxication to be affecting your ability to drive. It doesn't take much alcohol for your reflexes and cognitive response to be impaired enough to cause an accident, even if it's not obviously apparent. While there is some variation, the acceptable BAC levels were based on correlation with average results from testing for significant reflex and attention deficits.
You might be one of the outliers, but the odds are much better that you might are one of the myriad of people who delude themselves into thinking that they are outliers because their judgement is impaired. Unless you've actually personally undergone reflex/response testing by a third party in conjunction with BAC testing to judge your personal susceptibility to alcohol, your judgement on the subject after alcohol consumption is unreliable. However your ability to compensate for impairment in normal driving conditions wouldn't save you from an accident in an unexpected situation the way unimpaired reflexes would.
The small restriction on the few outliers is not a high price to pay for the safety of innocents. Nobody says you can't drink or drive, just that you have to exercise some level of personal responsibility and not do both (or for that matter, drive and consume any other drug that impairs your ability to drive safely)
Parent
Re:But does it work? (Score:5, Insightful)
Presuming it's the same summary that I read, it contained a mistake.
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. Then the fourth reading is averaged with the new average, and so on. 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.
This actually places more weight on the final reading, not the first.
Parent
Re:But does it work? (Score:5, Insightful)
You are correct. In the biz, we refer to this as an exponentially-weighted moving-average-filter. Recent samples are weighted more heavily than older samples.
y(n) = alpha*x(n) + (1 - alpha)*y(n-1)
The alpha value controls how much of the current input makes it to the output and how much of the old output stays. i.e. with an alpha value of 0.5, half of the new value is added to half of the old value. With an alpha of 0.1, 10% of the new value gets added to 90% of the old value.
This filter is nice because it doesn't require you to remember all the values that you want to average together, but it's a horrible way to get over the inherent noisiness in sensors.
Parent
Re:But does it work? (Score:5, Insightful)
This filter is nice because it doesn't require you to remember all the values that you want to average together
Why would you need to remember all the values? As long as you remember the number of values and their total you're fine.
Parent
Re:But does it work? (Score:5, Informative)
If you have a noisy sensor and are trying to keep a low-noise estimate of the input, while that input is changing, you do some sort of filtering on the data. The weighted rolling average described above is nice for a number of reasons, mainly it's simple to implement and simple to analyze. In some cases, other filters are better.
If you have a noisy sensor and want to measure a single unchanging input, you would want a different sort of filter. In this case, the simple arithmetic average works quite well.
As you correctly observe, the two filters of similar complexity. Which one you use should depend on the sort of input you're trying to measure. In this case, they used the former type of filter on the latter type of data, which is a definite no-no. This will result in data that is far noisier than you would otherwise expect from the raw sensor noise and the number of samples taken. When that noise could be the difference between a DUI conviction and and the cop telling you to drive home carefully, I'd say that's worth worrying about.
Parent
Re:Is this 1968? (Score:5, Insightful)
With an attitude like that, it's obvious that you have little experience with embedded systems...
Parent
Re:But does it work? (Score:5, Insightful)
code that doesn't pass static analysis and is ugly... well that pretty much defines 99% of the code out there.
It's more than ugly, it's difficult to maintain. Also, this point is largely irrelevent; 99% of the code out there isn't spitting out a number that says you're guilty of a serious offense.
Parent
Re:But does it work? (Score:5, Interesting)
No, but some no trivial amount of code is running the x-ray machine at the dentist, processing my credit card, managing my fuel injection, saving my thesis paper, and timing stoplights throughout my city.
We trust our lives and livelihoods to shitty code every day and the plain fact of the matter is that shitty code usually works. As programmers we like to think of ourselves as artists; creating a master piece of perfectly engineered code. In reality, all projects face budget and time constraints, most projects have legacy code which is hard to maintain, and most teams have at least one guy who just doesn't get it.
If the code works, and you can show empirically that the code works, that is proven beyond a reasonable doubt it my opinion. Not beyond any doubt, but that isn't the standard that our justice system is based upon.
Parent
Re:But does it work? (Score:5, Insightful)
Show me a programmer creating "perfectly engineered code", and I'll show you a programmer building up its resume.
Parent
Re:But does it work? (Score:5, Interesting)
I disagree. Anything upon which guilt or innocence rests on needs to be held to a higher standard.
For many other applications, especially non-government ones, if the code doesn't work well, then customers probably aren't going to buy it, and changes will be made. For instance, your example of fuel-injection code. If you don't do that correctly, you're going to have an engine that runs like crap and get poor economy. Cars that run poorly generally don't sell well. They might sell some, but as we see with GM and Chrysler, you have to do better than that to avoid bankruptcy.
Saving your thesis paper? The code in TeX is probably some of the most bug-free code around. At least I hope you're using TeX and not something crappy like MS Word for a thesis. But even MS Word isn't that bad, since so many businesses rely on it and don't have problems with random data corruption to my knowledge.
Timing stoplights is a good counterpoint to your example. In my experience, stop lights have horrible timing most places I go. It's almost like they're intentionally designed to make you stop at every single light, unless you drive at > 80mph on surface streets. Why is such poor performance accepted from our traffic lights? Because they're run by the government, and we the people don't have a choice. That's exactly the same as this breathalyzer crap: if you're accused, you don't get a choice about which breathalyzer they use on you. It's decided by the government (probably with help from bribes), and that's what they use, whether it works well or not.
Parent
Re:But does it work? (Score:5, Interesting)
Remember when it used to be you couldn't drunk drive?
Then it was you couldn't be behind the wheel while drunk?
Then it became you couldn't even be in the driver's seat with the car off while drunk?
Then it became you couldn't drive if you couldn't get out and walk in a straight line?
Then it became reciting your alphabet backwards...
Then suddenly, you couldn't have an arbitrary percentage of alcohol in your blood to do all those things.
Then it became whatever the machine said your blood alcohol might be.
There are no laws against drunk driving anymore. There are laws about not being able to potentially operate a vehicle if a machine determines you have enough alcohol on your breath.
Parent
Re:But does it work? (Score:5, Informative)
correction, you may refuse a roadside breath test, but not one at the police station.
Parent
Re:But does it work? (Score:5, Informative)
In all 50 states, refusal to take a breathalyzer at the police station will result in a 1 year(minimum) suspension of your drivers license.
In all 50 states, you can refuse to take a roadside breathalyzer as they're inadmissable in a court of law. If you have had even 1 drink, always ask to go to the station for a real breathalyzer. The PBT's, or portable breath testers, are wildly inaccurate and only give the police probable cause to arrest. It will not work in your favor to take it.
Parent
Re:But does it work? (Score:5, Interesting)
Actually, research I read when I got my DUI in 2007 seemed to indicate the release of alcohol vapors into the air by the lungs can vary widely between persons, by as much as 20%.
This has nothing to do with body size, type or metabolic rates that I'm aware of, but more research is obviously needed for the scientific community to reach a consensus. The sampling process is fundamentally flawed but the courts have routinely rejected any evidence to the contrary.
I don't know about 49 of the states, but in Washington state, if you want something more accurate than a breathalyzer, you have to demand the police take you to the hospital to have blood drawn at your own expense. They are required by law to comply, but 99% of DUI suspects know nothing of their rights.
If I got pulled over again that same night, I would have driven home without a DUI and even if they did manage to get me to perform parking lot special olympics(also called the field sobriety test), I would have asked for a lawyer. Like most first time offenders, I took a plea deal to avoid significant jail time and paid the ridiculous fine and took alcohol awareness classes. The whole thing was a farce, intended to make money.
I blew .086% and easily could have challenged the results in court, given the breathalyzer had a sticker on it that said it hadn't been calibrated in 2 years.
Parent
Re:But does it work? (Score:5, Interesting)
Had a buddy of mine leave a night club and he got pulled over for supposedly making an illegal left turn. Blew over the state's
However, the judge didn't care that there was no reason to be pulled over (with photos of the left-turn sign) since the cop explicitly said it wasn't due to erratic driving, *only* the 'illegal' left turn. Examples must be made. DUI upheld.
Hell, even I got pulled over once for simply driving at 2am, but my breathalyzer revealed a stunning 0.00% BAC. After chatting with the cop for a bit, turns out they were just looking for easy DUI targets, and I happened to be driving on the same road as them.
Parent
Re:But does it work? (Score:5, Insightful)
The majority of crashes and deaths aren't caused by people that blow a 0.086. They're habitual offenders who blow .25s.
Parent
Re:But does it work? (Score:5, Insightful)
Good question, but it needs to be reworded. Does it always work for all inputs?
Also important, if it's a poorly written mess, why is the company claiming that it works? I see no indication that they've done due diligence for a device used to convict people. Just because they've never observed it to fail, doesn't mean a thing.
Parent
Re:But does it work? (Score:5, Informative)
"Just because they've never observed it to fail, doesn't mean a thing."
Correct! This is a point that many people fail to understand. Testing can't prove that there aren't bugs. All it proves is that a bug did not occur. Failing a test just proves that a bug exists while passing all test just proves that you failed to find a bug. Passing many tests can boost your confidence that there are no bugs. Verification can prove that your code is correct but for most programs it is unfeasible.
Parent
Re:But does it work? (Score:5, Informative)
Parent
Re:But does it work? (Score:5, Interesting)
Well, if we assume the machine was sensitive up to the LD50 for ethanol of 0.5% BAC, then with only 4 bits of precision the uncertainty just from the rounding error is comparable to the difference between being over the limit and being completely sober. This was covered in the comments on Bruce Schneier's blog [schneier.com]. That one's probably wrecked a few peoples' lives too.
Parent
Re:But does it work? (Score:5, Insightful)
My first thought as well.
Of course, with poorly written code, it's hard to show whether or not the code ultimately works by examination of the code.
Then again, proving that the code works (which should be the standard when the code is analyzed in court) by code examination is very difficult even for well-written code.
Perhaps a better approach would be documented, repeatable testing of the device. When I challenge a radar gun, I get to ask about its calibration documents, but I don't think I get to debate the blueprints from which it was built.
My personal opinion - and before getting on an "innocent until proven guilty" kick bear in mind that I'm not a part of the court system in this case - is that the defense realizes that almost all software systems look awful and are trying to game their way out of a conviction they've probably earned.
That said, if for no other reason then to eliminate such gaming, there should be standards for testing and documenting the proper function of these devices. Any device that can't be calibrated and tested with sufficient certainty should be banned from use as evidence in court. If the device passes the test, then exactly how it does it shouldn't really matter.
Parent
Re:But does it work? (Score:5, Insightful)
Of course, with poorly written code, it's hard to show whether or not the code ultimately works by examination of the code.
Of course it works because it gives an end result instead of an error message.
The question every should ask is "Does it work accurately?" or "Does poorly written code skew the results?"
Can the defense prove that the code was written so haphazardly that it ignores some data or does it round incorrectly like Excel does? These things do and can happen with sloppy code.
That said, if the code is just poorly commended and indented correctly (*wink*) but does the math right and makes sure there isn't a sampling or rounding problem, then it isn't a problem.
Parent
Re:But does it work? (Score:5, Insightful)
Calibration and testing won't reveal all the edge cases that might cause errors. Consider a radar gun designed to take the average of five samples. You've got a car moving away from you at 70 MPH, and a duck flies into the beam for one sample, moving towards you at 5 MPH. This gives the following five samples:
70 70 70 -5 70
I can see a way that badly-written code would turn that into an average speed of 106 MPH (storing a signed char as an unsigned char, which would turn the -5 into a 251), and yet it would pass calibration and every test someone's likely to perform.
Parent
No. (Score:5, Informative)
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.
Parent
Re:No. (Score:5, Insightful)
As states lower their legal limits to the point where they intersect with non-impaired drinking drivers, especially with a
Parent
Code (Score:5, Insightful)
not written well, nor is it written to any defined coding standard
Ah, so it's like most of the code in the world.
Good! (Score:5, Insightful)
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.
Re:Good! (Score:5, Insightful)
But they weren't doing government contracting. The produced a good that was purchased by the government. There's a very big difference.
The key here is not that the government, or anyone, should own what they produced -- it's that when what they produced is used to convict someone, that person has the right to examine the methods used.
It's not about openness, at all. It's about the right to a fair trial; openness is just a side effect.
Parent
No surprise (Score:5, Insightful)
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.
Re:No surprise (Score:5, Insightful)
80% of the code in business fits this description
how much of that code is given police powers to arrest someone?
Parent
Just remember (Score:5, Insightful)
DUH.... (Score:5, Interesting)
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.
Looks like the NJ Supreme Court doesn't care (Score:5, Informative)
A pyhrric victory for open source and code review. (Score:5, Insightful)
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.)
But is it broken? HELL YES!!! (Score:5, Informative)
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.
Re:Coding Standard (Score:5, Insightful)
Parent
Re:Coding Standard (Score:4, Insightful)
Er, why would it need or be expected to be? It's a commercial product. I don't think most bank websites are "coded" to any specific standard either.
From the article:
1. The Alcotest Software Would Not Pass U.S. Industry Standards for Software Development and Testing: The program presented shows ample evidence of incomplete design, incomplete verification of design, and incomplete "white box" and "black box" testing. Therefore the software has to be considered unreliable and untested, and in several cases it does not meet stated requirements. The planning and documentation of the design is haphazard. Sections of the original code and modified code show evidence of using an experimental approach to coding, or use what is best described as the "trial and error" method. Several sections are marked as "temporary, for now". Other sections were added to existing modules or inserted in a code stream, leading to a patchwork design and coding style.
Ok. Would you want to have something that can cause you to get convicted because it wasn't documented or even tested fully - ("Oh, Crap. That constant should have been 0.001, not 0.01. Ooops. Blood Alcohol level was 0.008, not .08. Sorry !")
Common sense (if it WERE common) should indicate that there should be full tests for a wide range of values performed with the written tests and expected values verified and available to prove that the device/software actually does detect the proper levels of alcohol.
Parent
Re:not written to a coding standard? (Score:5, Insightful)
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.
Parent
Re:Lint is crap (Score:5, Interesting)
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.
Parent
Re:Lint is crap (Score:5, Interesting)
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.
Parent