3 ms·
> Toyota engineers cramped tens of thousands of lines in a single file and the lines freely update hundreds of global variables. While the "single file" part i
by GuB-42 3y ago
> Toyota engineers cramped tens of thousands of lines in a single file and the lines freely update hundreds of global variables.
While the "single file" part is not great, using all global variables in an embedded system can be a good thing. I've worked on a critical piece of software for aircraft that did this deliberately, for safety reasons.
One of the most important criteria for that software is determinism, which means no dynamic allocation since it is hard to predict how the allocator would behave. The stack can also be very limited in size, so what remains are global variables.
It also makes debugging easier. You know exactly which variable corresponds to which address in memory. And with a probe, you can know the full state of the program at any time. That's also how we tested "impossible" conditions (for coverage): by overwriting specific memory addresses.
Many of the reasons why globals are bad didn't apply there. We had no concurrency, no resources to share with other processes, in fact, we didn't even have an OS at first, Nothing was dynamic, all arrays were of fixed size, including strings, which were array of characters padded with spaces to the appropriate length.
Of course, we documented usage of these variables, proper up-to-date documentation was not an option as it was certified software. It was one of the most boring job I ever had, and it is probably for the best.
- thebruce87m 3y agoAs an embedded engineer I’ve never heard of this and it seems… unwise. Yes, we avoid dynamic memory allocation but using globals for everything? Assuming C: For inter-file access static variables with getters/setters achieves the same thing and makes it easier to split/test I’ve never went as far as not using local variables in functions but you could use static here too to avoid the possibility of two functions sharing the same variable.
- GuB-42 3y agoWe still had local variables, for internal calculations and the likes of course, but most of the interface was done through globals. (btw, it was indeed C) Perhaps what is missing is that the way we did testing was a bit unconventional. That is, we didn't have unit tests. Instead, we did it all through integration testing on the real hardware. And setting these globals was how we got coverage. We also had a particularly good traceability, so we knew exactly which tests to run after each code change and get our coverage back, which made up for the fact that we couldn't tests the functions independently. It was a rather successful project, we got audited a couple of times with only minor issues. It certainly made testing more difficult, but we in exchange, it was much closer to real life conditions. Note that it was a while ago, newer project use a more modern approach with a continuous integration platform, unit tests with an emulator, etc... We also use less C, instead using industry specific tools and certified code generators, multitasking RTOSes, etc... With C and ADA for the inner and legacy parts.