GCC Coding Conventions

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.

Portability

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.

ChangeLogs

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.

Testsuite Conventions

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.

Miscellaneous Conventions

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_MARKs should be done by comparing against error_mark_node rather than by comparing the TREE_CODE against ERROR_MARK; see message.