This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Prototypes [was Re: Patch for bugs 772 and 17913]
- From: Roger Sayle <roger at eyesopen dot com>
- To: Gerald Pfeifer <gerald at pfeifer dot com>
- Cc: Gábor Lóki <loki at inf dot u-szeged dot hu>, Mark Mitchell <mark at codesourcery dot com>, "Joseph S. Myers" <joseph at codesourcery dot com>, <gcc-patches at gcc dot gnu dot org>, Richard Henderson <rth at redhat dot com>
- Date: Thu, 5 May 2005 12:58:31 -0600 (MDT)
- Subject: Re: Prototypes [was Re: Patch for bugs 772 and 17913]
On Thu, 5 May 2005, Gerald Pfeifer wrote:
> On Tue, 3 May 2005, Roger Sayle wrote:
> > [http://gcc.gnu.org/codingconventions.html]
> > Admittedly, this document is some what out of date, as it doesn't
> > describe GCC's decision to move to C89/C90 and the default authority
> > http://www.gnu.org/prep/standards/standards.html still recommends
> > using K&R style function declarations and PARAMS-like macros in
> > function prototypes, which have recently been abandoned by the GCC
> > project: http://www.gnu.org/prep/standards/standards.html#Standard-C
>
> Any chance you could cook up a patch for codingconventions.html
> describing these differences versus the GNU Coding Conventions?
There was a certain inevitability in the above thread that I'd manage
to get volunteered to document the prefered GCC coding style. :)
How about something like this? I appreciate that not everyone agrees
with these provisional ammendments (yet), but formalizing things gives
people something concrete to argue over.
* codingconventions.html: Update to describe currrent preferences.
Index: codingconventions.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/codingconventions.html,v
retrieving revision 1.40
diff -c -3 -p -r1.40 codingconventions.html
*** codingconventions.html 27 Jan 2005 11:11:56 -0000 1.40
--- codingconventions.html 5 May 2005 18:56:43 -0000
*************** of the ChangeLog entry.</p>
*** 74,80 ****
<h2>Portability</h2>
<p>There are strict requirements for portability of code in GCC to
! older systems whose compilers do not implement the ISO C standard.
See <a
href="http://gcc.gnu.org/cgi-bin/cvsweb.cgi/~checkout~/gcc/gcc/README.Portability?content-type=text/plain&only_with_tag=HEAD">README.Portability</a>
for details of some of the portability problems that may arise. Some
--- 74,83 ----
<h2>Portability</h2>
<p>There are strict requirements for portability of code in GCC to
! older systems whose compilers do not implement all of the ISO C standard.
! GCC requires at least an ANSI C89 or ISO C90 host compiler, and code
! should avoid pre-standard style function definitions, unnecessary
! function prototypes and use of the now deprecated @code{PARAMS} macro.
See <a
href="http://gcc.gnu.org/cgi-bin/cvsweb.cgi/~checkout~/gcc/gcc/README.Portability?content-type=text/plain&only_with_tag=HEAD">README.Portability</a>
for details of some of the portability problems that may arise. Some
*************** system. Exceptions may be made to this
*** 105,110 ****
--- 108,125 ----
the release cycle, to reduce the risk involved in fixing a problem
that only shows up on one particular system.</p>
+ <p>Avoid the use of identifiers or idioms that would prevent code
+ compiling with a C++ compiler. Identifiers such as <code>new</code>
+ or <code>class</code>, that are reserved words in C++, should not be
+ used as variables or field names. Explicit casts should be used to
+ convert between <code>void*</code> and other pointer types.</p>
+
+ <p>Function prototypes for extern functions should only occur in
+ header files. Functions should be ordered within source files to
+ minimize the number of function prototypes, by defining them before
+ their first use. Static function prototypes should only be used
+ when necessary, to break mutually recursive cycles.</p>
+
<h2>Makefiles</h2>
Roger
--