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

[Gábor Lóki <loki at inf dot u-szeged dot hu>]

Roger Sayle wrote:
> > > > +static tree contains_label_1 (tree*, int*, void*);
> > > > +static bool contains_label_p (tree);
> > >
> > > You only need to prototype the constains_label_p call, as it's
> > > subroutine contains_label_1 is only used after it's defined.
> > > If both these routines were moved earlier in fold-const.c, you
> > > wouldn't need to prototype either.
> >
> > Of course, the prototype of 'contains_label_1' isn't necessary.
> > Personally, I prefer using prototypes in this way, but I can remove it.
>
> Richard Henderson recently stated his position on this issue in
> http://gcc.gnu.org/ml/gcc-patches/2005-04/msg02907.html
>
> 	You'll say its needed for this decl, but this decl isn't needed
> 	due to function ordering.  Indeed, I make it a habit not to
> 	pre-declare anything unless forced.  I prefer functions to
> 	simply be ordered such that the decls aren't needed.

That is a understandable reason, but I dissagree.
GCC contains many source files which are full of small, medium or huge (oh
my god) sized functions. If we want to make GCC easily maintainable
we should divide them into more logical parts. For example.:

--- file.{c,h} ---
/* Initial copyrights... */

/* Describe the contents... */

Local variables / functions (prototypes)...

/* Logical part 1. Describe it... */

Functions for logical part 1, etc. ...

....

/* Logical part n. Describe it... */

Functions for logical part n, etc. ...
---

In this aspect, if all prototypes are listed in the beginning of the file
this'll give an opportunity to see them like a table of contents. On the
other hand if you open a file, the static prototypes are the first you see,
and if the amount of these is small you could be easily fobbed about the
complexity of algorithms/files. IMHO we should not do the compiler/linker's
job about reordering functions while writing down the source code.

One more thing, If it is problem that there are one more function declarations
which have to be updated I can say that if you change something in the
function declaration you'll always check all occurrences of the function to
follow the changes. So IMHO one more line to update doesn't matter.

Furthermore the structure which is sketched above (or something like that)
could really help understanding algorithms/files for others.

br,
  Gabor Loki