Re:A Case Study of Toyota Unintended Acceleration and Softwa...
by magila on Saturday January 17, 2015 @08:09PM
(#8906205)
I'm not going to defend the other points, but most variables being global is not at all unusual for code like this. These sorts of realtime embedded applications typically have no heap allocation, so the only way to define persistent storage is as statically allocated globals. Modularization in these systems is done by convention, e.g. by limiting which include files are visible to a compilation unit.
[ Parent
| on HN ]
Re:A Case Study of Toyota Unintended Acceleration and Softwa...
by jacquesgt on Saturday January 17, 2015 @09:30PM
(#8906374)
Non-stack variables can be static instead of global. Either file-scoped or function-scoped.
Re:A Case Study of Toyota Unintended Acceleration and Softwa...
by jwilliams on Saturday January 17, 2015 @10:16PM
(#8906467)
Exactly.
This is also broken down on slide 40 - local static and file static variables.
Re:A Case Study of Toyota Unintended Acceleration and Softwa...
by DangerousPie on Saturday January 17, 2015 @09:18PM
(#8906359)
It's strange that the slides don't seem to mention this point at all, even though the author is presumably an expert in this field. Why would he make such a big point of this if it's commonly done in the field?
Re:A Case Study of Toyota Unintended Acceleration and Softwa...
by threeseed on Saturday January 17, 2015 @09:59PM
(#8906429)
There is a difference between being in an expert in the theory of software development and being an expert in the reality.
The theory says that bad software is written when you don't have 100% test coverage, static analysis on checkins, peer review, pair programming, the usual guidelines around encapsulation, inheritance etc. The reality is that bad software mainly comes about through poorly thought out requirements, bad initial architecture decisions and ridiculous time constraints.
It's always a shame when you see stories like this that those aspects never really get investigated or analysed.