2. BFD programming guidelines
There is a lot of poorly written and confusing code in BFD. New BFD
code should be written to a higher standard. Merely because some BFD
code is written in a particular manner does not mean that you should
emulate it.
Here are some general BFD programming guidelines:
-
Follow the GNU coding standards.
-
Avoid global variables. We ideally want BFD to be fully reentrant, so
that it can be used in multiple threads. All uses of global or static
variables interfere with that. Initialized constant variables are OK,
and they should be explicitly marked with const. Instead of global
variables, use data attached to a BFD or to a linker hash table.
-
All externally visible functions should have names which start with
`bfd_'. All such functions should be declared in some header file,
typically `bfd.h'. See, for example, the various declarations near
the end of `bfd-in.h', which mostly declare functions required by
specific linker emulations.
-
All functions which need to be visible from one file to another within
BFD, but should not be visible outside of BFD, should start with
`_bfd_'. Although external names beginning with `_' are
prohibited by the ANSI standard, in practice this usage will always
work, and it is required by the GNU coding standards.
-
Always remember that people can compile using `--enable-targets' to
build several, or all, targets at once. It must be possible to link
together the files for all targets.
-
BFD code should compile with few or no warnings using `gcc -Wall'.
Some warnings are OK, like the absence of certain function declarations
which may or may not be declared in system header files. Warnings about
ambiguous expressions and the like should always be fixed.
This document was generated
by system on December, 2 2004
using texi2html