Slashdot Mirror

These tests are not pseudo science from my understanding, if you have not been drinking they will return that result.

No, not pseudoscience, but a) not necessarily good science, and b) that assumes the Breathalyzers are properly designed, built, maintained, regularly calibrated, used, reported and recorded.

Those are awfully big assumptions to make, especially when so many, like, you, assume that they're infallible magic boxes.

Breathalizer source code analysis. Slashdot discussion thereof

It seems like a lot of the car manufacturers are having some major software issues. This Range Rover issue certainly isn't the worst one.

For instance, see this blog post (which links to US court testimony documents) where an embedded software expert (Michael Barr) reviews Toyota's code and finds numerous flaws:

http://embeddedgurus.com/barr-...

Did Toyota fix these flaws? Who knows? Toyota still denies that there's even a problem. They released an update to the Prius last year which corrected a problem with premature engine shutdown, but that was only for limited number of Priuses. Accorrding to Michael Barr, these software issues affect Toyota, Lexus (and possibly Scions) made in the last ten years.

The only way in my mind to be pretty sure our cars are safe is for the manufacturers to release their software as open source, where it can be reviewed and any flaws are found. While folks wouldn't be able to find *every* bug, it sure would be a lot better than we have now.

You mean, people accidentally mashing both pedals at the same time?

Possibly. But there was a published third-party analysis of Toyota's ECU software which made me reluctant to buy one:

http://embeddedgurus.com/barr-...

I was glad to see that my new SUV automatically cuts the gas if it detects you pressing both pedals at the same time, even if due to a bad sensor or crashed throttle-monitoring process (yeah, I know, that means no left-foot braking, but if you're doing that in an SUV, you're probably doing it wrong).

I think maybe this is the article (blog post by Miro Samek) that youre referring to?

I've heard NOTHING that leads me to believe me to believe that these cases of "uncontrolled acceleration" were anything of the sort.

Then you must be an all knowing expert. Oh wait...

http://embeddedgurus.com/barr-...

So a tree falls in the forest but you can't hear it, then it must have never been growing there in a first place!

Toyota's fine was not just about sticking pedals (and initially making deceptive statements about the safety of those pedals). Toyota's fine was in part for claiming that sticking pedals were the sole cause of unintended acceleration when in fact multiple defects in Toyota’s engine software directly caused at least one (decided by a jury) other crash.

An Update on Toyota and Unintended Acceleration Barr Code

U.S. Fines Toyota $1.2 Billion but Defers Criminal Prosecution Over Vehicle Safety Deceit - IEEE Spectrum

This is an important safety (and technology) issue that has flown mostly under the radar. I believe that is in part because journalists and the public believe they got their answer years ago, when in fact new evidence, expert testimony, and court verdicts have come to light. I think the issue is important enough that this misconception should be corrected whenever it's reported.

My opinion, not my employer's.

Software tests are also capable of missing certain circumstances. Even 100% coverage doesn't make code bullet-proof. There are bugs that only occur due to circumstance, such as stack overflow or undefined behavior. Normal unit test might not expose latent bugs. Just read this.

For whatever reason the one of the original links was no longer available when I revisited one of the links in the OP today:

http://embeddedgurus.com/barr-code/2013/10/an-update-on-toyota-and-unintended-acceleration/

But Google Cache still has a copy...

http://webcache.googleusercontent.com/search?q=cache:http://embeddedgurus.com/barr-code/2013/10/an-update-on-toyota-and-unintended-acceleration/

This is a VERY concerning direction for programmers in the USA, as of course complex software by definition cannot be proven correct

Well, this software was proven incorrect by the Barr Group.

This is a very good thing for software engineering in the USA, because the newly required level of professionalism means we will no longer be able to get away with shoddy work, and it means outsourcing will be the first to go.

"You did not post a compile able "*.c" file but a "*.h" file."

As I said, the file I got the code from is e100.c See lines 494 through 571. Also, there is no real difference between a .h and a .c file for the purposes of our discussion since both are comprised of two fundamental atoms, to wit comments and code. The purpose of a header file is to include certain elements of a program's source code that will be reused by multiple files so that they can share interfaces and data structures. When no such sharing is desired they don't belong in a header file. In this case the struct has file scope, and putting it in the .c file ensures that nobody else can or will manipulate elements of the struct. This is done in order to properly implement abstraction.

As you can see, what you don't know about what you are doing could literally fill a book.

"I suggest you consult your favorite dictionary what a 'janitor' is :D"

I know exactly what it is, but you seem to be the one who cannot understand simple English. My statement is that the best thing one can say about your knowledge of software engineering is that you would probably do well emptying trash, mopping floors, and cleaning toilets.