Go forward to Clean Design.
Go backward to Longjmp Support.
Go up to Top.
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:
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
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