GDB is generally written using the GNU coding standards, as described in `standards.texi', which is available for anonymous FTP from GNU archive sites. There are some additional considerations for GDB maintainers that reflect the unique environment and style of GDB maintenance. If you follow these guidelines, GDB will be more consistent and easier to maintain.
GDB's policy on the use of prototypes is that prototypes are used to declare functions but never to define them. Simple macros are used in the declarations, so that a non-ANSI compiler can compile GDB without trouble. The simple macro calls are used like this:
extern int memory_remove_breakpoint PARAMS ((CORE_ADDR, char *));
Note the double parentheses around the parameter types. This allows an arbitrary number of parameters to be described, without freaking out the C preprocessor. When the function has no parameters, it should be described like:
void noprocess PARAMS ((void));
The PARAMS macro expands to its argument in ANSI C, or to a simple
() in traditional C.
All external functions should have a PARAMS declaration in a
header file that callers include. All static functions should have such
a declaration near the top of their source file.
We don't have a gcc option that will properly check that these rules have been followed, but it's GDB policy, and we periodically check it using the tools available (plus manual labor), and clean up any remnants.