Re:A case study of Toyota unintended acceleration and softwa...
by monocasa on Monday May 02, 2022 @12:42PM
(#31237482)
The rumor I heard at the time was that large portions of the code were autogenned out of a Matlab model of the engine, and that was where the globals and awful code complexity metrics came from.
Re:A case study of Toyota unintended acceleration and softwa...
by stefan_ on Monday May 02, 2022 @09:35PM
(#31243329)
Yep. This is widespread practice in the industry and is arguably far superior to someone actually trying to model it all in C. It just looks weird in a disassembler because you end up with a million global variables and essentially no control flow.
(It's specifically Matlab Simulink for those playing along at home)
Re:A case study of Toyota unintended acceleration and softwa...
by chillingeffect on Tuesday May 03, 2022 @08:15AM
(#31247340)
Ive exported several simulink models. Long functions, yes. Globals, no.
Re:A case study of Toyota unintended acceleration and softwa...
by monocasa on Tuesday May 03, 2022 @11:02AM
(#31249197)
I've integrated several simulink models; they had an incredible amount of globals.
Re:A case study of Toyota unintended acceleration and softwa...
by jacquesm on Monday May 02, 2022 @12:28PM
(#31237306)
Indeed, spaghetti code is bad, but spaghetti data manipulated by spaghetti code is orders of magnitude worse.
The thing that I never got is why there are plenty of high level languages that have 'global' more or less as the default. This is asking for trouble. Side effects should be very carefully introduced and reasoned about and kept to an absolute minimum, not be the default sauce to sprinkle across your codebase, the possible number of states increases very rapidly if you do that.
Re:A case study of Toyota unintended acceleration and softwa...
by kevin_thibedeau on Tuesday May 03, 2022 @12:06AM
(#31244485)
Dynamic allocation is generally forbidden in this application so all system state has to be in global or static variables. Otherwise you'd have to invest in formal analysis tools to prove that memory won't be exhausted.
Re:A case study of Toyota unintended acceleration and softwa...
by 2143 on Monday May 02, 2022 @02:08PM
(#31238638)
> If you're trying to go around corners as fast as possible in a front-wheel drive car
1. Please don't do circus on public roads.
2. If you're on private roads, well, you know, front-wheel-drive cars tend to handle poorly in fast corners. Do yourself a favour and get a RWD or AWD or something.
Re:A case study of Toyota unintended acceleration and softwa...
by sidewndr46 on Monday May 02, 2022 @02:37PM
(#31239036)
If you're declaring a variable as volatile and accessing it from separate threads, it is going to be "fucking nasty" in so many ways.
Global variables in that kind of codebase might be -really- hard to keep track of how you are accessing and writing them :/.
This gets really fucking nasty when you're doing things like setting it to volatile and potentially accessing it across threads and you end up with a partial write and then doing a read, etc.
I'm sure the axiom of "it's never tested as much as we want" still probably applies here and that's slightly terrifying.
also FTA: 2272 - global variable declared with different types
“Spaghetti code”: Incomprehensible code due to unnecessary coupling, jumps, gotos, or high complexity
Yeah that sounds fun. really fun. This is why I purposefully never work on any system that could kill someone. I just can't imagine being in charge of something like that and not wanting to go insane with knowing my code wasn't checked enough. or I wasn't careful enough.