There are some additional coding conventions for code in GCC, beyond those in the GNU Coding Standards. Some existing code may not follow these conventions, but they should be used for new code. If changing existing code to follow these conventions, it is best to send changes to follow the conventions separately from any other changes to the code.
There are strict requirements for portability of code in GCC to
older systems whose compilers do not implement the ISO C standard.
See README.Portability
for details of some of the portability problems that may arise. Some
of these problems are warned about by gcc -Wtraditional
,
which is included in the default warning options in a bootstrap.
(Code outside the C front end is only compiled by GCC, so such
requirements do not apply to it.)
The programs included in GCC are linked with the
libiberty library, which will replace some standard
library functions if not present on the system used, so those
functions may be freely used in GCC. In particular, the ISO C string
functions memcmp
, memcpy
,
memmove
, memset
, strchr
and
strrchr
are preferred to the old functions
bcmp
, bcopy
, bzero
,
index
and rindex
; see messages 1 and 2. Note
if changing the form used in existing code that care must be taken
over the different argument order used by memcpy
and
bcopy
, and that bcopy
is equivalent to
memmove
though in most cases memcpy
is the
appropriate replacement.
GCC requires ChangeLog entries for documentation changes (see message), though for changes to the GCC web pages (as opposed to the libstdc++-v3 ones) there is no appropriate ChangeLog file and the CVS logs suffice.
There is no established convention on when ChangeLog entries are to be made for testsuite changes; see messages 1 and 2.
The testsuite READMEs discuss the requirement to use abort
()
for runtime failures and exit (0)
for success.
For compile-time tests, a trick taken from autoconf may be used to evaluate
expressions: a declaration extern char x[(EXPR) ? 1 :
-1];
will compile successfully if and only if EXPR
is nonzero.
Where appropriate, testsuite entries should include comments giving their origin: the people who added them or submitted the bug report they relate to, possibly with a reference to a PR in GNATS. There are some copyright guidelines on what can be included in the testsuite.
Code should generally use abort ()
rather than
assert ()
for tests for "can't happen" conditions; see message.
Such conditions should not be generated by invalid user input. If the
checks are expensive or the compiler can reasonably carry on after the
error, they may be conditioned on --enable-checking
.
Code in GCC should use the following formatting conventions:
Use... | ...instead of |
---|---|
!x | ! x |
~x | ~ x |
-x (unary minus) | - x |
(foo) x (cast) |
(foo)x |
*x (pointer dereference) |
* x |
Macros names should be in ALL_CAPS
when it's important
to be aware that it's a macro (e.g. accessors and simple predicates),
but in lowercase (e.g., size_int
) where the macro is a
wrapper for efficiency that should be considered as a function; see
messages 1
and 2.
Testing for ERROR_MARK
s should be done by comparing
against error_mark_node
rather than by comparing the
TREE_CODE
against ERROR_MARK
; see message.