Re: A patch to constify gcc.c (Really, prototyping in config/*/*.h)

["Kaveh R. Ghazi" <ghazi at caip dot rutgers dot edu>]

 > From: Jeffrey A Law <law@hurl.cygnus.com>
 > 
 > Similarly, building a scheme which allows for clean prototyping of
 > functions in the backend files is probably more important than
 > -Wwrite-strings too since we could then start looking at missing
 > prototype warnings (I've seen far more bugs due to missing prototypes
 > than write-strings problems over the years in gcc).
 > 
 > Bernd's scheme for doing this held the most promise of the stuff I've
 > seen proposed over time.  It's not something I think we want to try
 > and tackle before egcs-1.2 though.
 > jeff

	As I recall, Bernd's scheme involved splitting the target header
file into two files, the macros and the prototypes.  The macros would
remain in the place they are now, and the new prototypes file would have
to be included in each individual C file *after* headers like
machmode.h, rtl.h, etc which declare the major types.  I.e. I don't
think you can include the new prototype file once in some generic place. 

	This would work, but involves touching almost every single
file in gcc sources (essentially any file which includes {h}config.h)
on top of the work required to split each individual target header.  I
guess you might also have to diddle with configure.in so it chooses
the right prototype file.  You'd also have to make sure you provided
for mixing both the old and the new mechanism or you'd have to split
every single target header at the same time to avoid breaking any of
them.  Seems like a lot of work.

	I had been kicking this around in my head a while back and
came up with a different approach.  If we arrange to have the right
types and support macros defined early enough, we can just prototype
the functions at their current location without splitting the target
headers.  If we do this, we can protoize each target header as time
permits.

	We need to:

1.  Make sure PROTO()/PARAMS() are defined early enough to be used in
config/foo/foo.h.

2.  Make sure things like machine_mode, rtx, etc are declared early
enough for the same purpose.

	I've already done and installed #1 a few months ago as part of
the ansidecl.h/gansidecl.h unification.  You can prototype functions
which use builtin types today.  (E.g. I believe v850.h does this.  It
used to define PROTO itself, now it relies on gansidecl.h which always
gets included before it.)

	For #2, I have a patch I was playing with from back in
November to get just the definition for machine_mode out of machmode.h
and make it available early enough for the target headers to use it.
Analogous patches could get the other necessary types.

	If you think this is worthwhile to consider, I'll dust off my
old patch and post it along with a prototyping of a representative
function as a proof of concept.  Let me know if you are interested.

		--Kaveh
--
Kaveh R. Ghazi			Engagement Manager / Project Services
ghazi@caip.rutgers.edu		Qwest Internet Solutions