435 karma · joined May 15, 2012
There's a few more related articles on his blog if you search, and I've read of it being implicated elsewhere, that's not to say the software calling that much was doing the right thing, just that it had impact.
It chops it up to AC for the transformer.
If the inputs here are coming from something external to the program, such that the compiler can't know the value of x then the machine code should be faithful to the language statements, it's a bug if overflow occurs which may have other runtime implications, but the compiler isn't going to remove some chunk of code, etc. because of it.
From their testing page SQLite say they also test boundary conditions (I don't know to what granularity that is though) which which may catch something like this, which is agreeing that instruction level coverage isn't enough. They also run their tests with all the various sanitisers enabled.
Isn't this the same case in Rust, the non-release builds would need to see a suitable test case for the overflow check to cause a panic.
I guess I'm asking is this example relevant to concerns about undefined behaviour and optimising compilers vs. Rust? Since the function is input value dependent in practice isn't this more like implementation defined behaviour at runtime, in that a platform will alway provide a consistent behaviour, e.g. overflow, trap, saturate, etc.?
I've followed regehr's blog for a few years, I've read a lot about Rust, but I'm mostly working in higher level dynamic languages and don't have a lot of hands on experience with C or Rust and just wondering if I'm missing some subtlety here.
Still it would be nice if there were inexpensive ways to check emissions for your self while tinkering.
However, I think fuel maps vs. catalyst removal are largely similar, it'll either be picked up on the next inspection or VOSA can do spot checks if they think something is up. I don't think DRM / technical measures for locking the ECU are appropriate much like I wouldn't be happy if the catalyst and exhaust system were installed such that only the manufacturer could replace them.
Perhaps one would only use a performance map when using the car on a race track, it'd be a shame to replace all the electronics just for that.
I'm also not a fan of things like geo-fenced speed limiters, and replacement components that have to be coded to the car by the dealer.
My cars are old (1998) Nissan Skylines, who's ECUs are pretty basic, asides from killing the engine there's not much you can do to cause more issue than a mechanical modification like adding a larger turbo, or maintenance neglect. The ABS and traction control are handled by physically separate ECUs, though I imagine things are more integrated in the main drive train ECU in modern cars.
While I haven't modified the existing or written my own firmware to load on the ECU that mostly due to lack of time, one of them came from Japan with a Piggy Back ECU installed which intercepts the inputs / outputs to override the mapping of the OEM ECU to tune for other mechanical modifications. An alternative is to buy an aftermarket ECU or build a custom one, those tend to have less integrated safety features (stability control, etc.) than the OEM ones and integrate less well with the car's other systems, I'd expect them to cause more issues overall than relatively simple modifications of the OEM firmware.
I'm sure there are extremes where people may cause problems, but this kind of thing has been happening since cars have had computers so I doubt there's any great calamity around the corner.