Normally in C, to define a function, you create a prototype at the top. This is so you don't surprise the compiler when you start compiling functions later on with undefined functions inside. The caveat is that if you define a function before it's used, you don't need a prototype. It's always good practice to prototype your function though, so that you don't put the cart before the horse.
Rules of engagement does not use prototypes. There is a proto.c file where they are supped to go, but it was not current and all the functions are defined before use in the code itself. However, in rules0.c the definitions were valid, but oddly formed. In fact, I didn't even know you could do it like this
Here's an example.
int Restrict(val, l, u)
int val, l, u;
if (val < l) return(l);
if (val > u) return(u);
The top two lines should be combined like so .
int Restrict(int val, int l, int u)
This makes the definition more pototype-y. Because the variables were not typed in the first example, Intellisense didn't register it as a function and was "invisible" to my IDE. (They compiled fine though) My job today was to go though rules0.c and correct all the definitions. While I was at it I found the FlashButton() function that was calling ColorMask() that was giving me all the grief. As opposed to relying on an old legacy color function, I can rewrite FlashButton() to flash selected buttons in a more modern way and not relying on legacy color masks at all.
While I was at it I also updated all the documentation in rules0.c for Doxygen.Now I shouldn't have any lost functions anymore. I didn't do any of the variable documentation yet, but now I can modernize some of the more "middleware" functions.
|Rules0.c is documented now|