Re: Prototypes [was Re: Patch for bugs 772 and 17913]

[Roger Sayle <roger at eyesopen dot com>]

On Thu, 5 May 2005, Mark Mitchell wrote:
> I like it, except I wouldn't say "Static" function prototypes.  Do you
> mean the C keyword "static" (i.e., <code>static</code>)?  Or should we
> just drop the word entirely?

My apologies, I'm not a very good word-smith.  I agree that dropping the
"static" is much less confusing, see the revised patch below.

My motivation was that I was trying to kill two birds with one stone,
by categorizing function prototypes into two kinds; local declarations
that prefixed are with the "static" keyword which should only appear
in .c files, and global declarations that are prefixed with the "extern"
keyword that should only appear in .h files.

The intent is to avoid ugliness such as this example from cfglayout.c:

>> extern bool cfg_layout_can_duplicate_bb_p (basic_block);
>>
>> bool
>> cfg_layout_can_duplicate_bb_p (basic_block bb)
>> {
>>   ...

i.e. there seems to be no good reason for prototyping a function as
"extern" immediately before it's definition.  Unless of course I'm
missing something?  The other misuse of extern prototypes in .c files
is to subvert/avoid correctly importing an interface via its' header
file, which should also be discouraged.  For example, changing the
interface of cfg_layout_can_duplicate_bb_p above, may cause problems
if the prototype in cfgrtl.c isn't updated to match.  This class of
problem can't be detected at compile-time as currently written.


Take 2:


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 20:19:54 -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&amp;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&amp;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.  Function prototypes should only be used when
+ necessary, to break mutually recursive cycles.</p>
+

  <h2>Makefiles</h2>


Roger
--