In my previous blog post about the C Tool Chain, I mentioned a post about configuring the C compiler, which is what this blog will discuss. Please note that I will not be talking about linkers or linking, just compiling.
In a world of complex systems, it may be easy to forget some of the basic concepts that build these systems. Software applications can consist of hundreds of individual files as part of one very large project. Those files all work together to achieve amazing functionality within an embedded system. There are instances where a project may include files written by teams located in different countries. We like to think that when this software is put into production all the bugs have been discovered and the software will work perfectly. Unfortunately, there always seems to be unintended use or a sequence of events that result in undesired functionality. Other times, there is just a plain old bug that managed to find its way into production software.
It certainly can be scary looking at a long bug list with a short deadline, but identifying and fixing software bugs can be manageable with a few strategies.
A second set of eyes.
Sometimes a very simple software error can be staring at us, but we miss it because we have been staring back so long. An example I faced was a section of code appeared to be setting a value used elsewhere in the code, but that value was never changing. When I finally had someone look at that code for me, the first question was “Isn’t that a pointer?”
Recently I was working on some embedded software that someone else wrote. I needed to add some new functionality to the code, and I was working through how the existing code was working. In particular, the software was parsing a file, and the previous developer had done a good job of sending out diagnostic messages to the terminal, and the code was parsing a line of the file as a bad record.
Well as a good little developer, the first thing I did was