paulmlewis

They're a big enough problem that they created Rust to deal with them.

Nor your boots! :-)

> The primary chops up the high-voltage DC from the PFC circuit and feeds it into the transformer.

It chops it up to AC for the transformer.

heh, brings back memories, we had a real-world Logo Turtle at secondary school in about 1990. This one's a little shinier though.

We have plenty of human biting mosquitos in the UK, I'm quite allergic to some of them.

I ask this from a position of seeking knowledge rather than being adversarial, the discussions on undefined behaviour from a C language perspective always seem muddled to me between what's undefined at the C language level such that a compiler might take advantage of it and produce results that would be unexpected looking at the code, vs. the machine code generated faithfully represents the language statements but a bug may be present when processing some external input at runtime.

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.

Does it need to be? I think the suggestion is allow using your own tablet with a standard interface, if it breaks in a few years replace it with a newer one. That way the you're not stuck with the obsolete infotainment unit that would have been built into the car.

Thanks for mitmproxy, used it for the first time the other day :-)

That's a fair point, my cars are old enough to come under the older UK road tax rules so are not taxed based on emissions, but their emissions are better than the requirements for their age.

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.

I think the majority of modifications are simply adjusting the calibration or lookup tables for things like fuel maps, enabling / disabling things like key left in ignition buzzers and the like, mostly data items rather than code modifications. There may be more adventurous modifications like adding launch control to a performance cars, but that may just be enabling existing code rather than adding new code.

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.

I'm sure there's some irony in that sentiment ;-) Aside from the VW thing I think pretty much all diesels are above emissions standards in open road testing.