This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: system.h


 > From: John Carr <jfc@mit.edu>
 > 
 > I have two comments on the new system.h.
 > 
 > It includes too much.  Most of gcc doesn't need more than the ANSI C
 > declarations: abort, stdio, string, and character functions.  All the
 > non-ANSI header files, if included at all, should be conditional on
 > the .c file requesting them.  Only a few would need to.
 > 

John,

	Thanks for taking the time to look at the new system.h and for
your comments.

	With respect to the amount system.h includes, I don't agree
with your view that it includes too much.  You don't state what you
perceive as the disadvantage to including various files, other than to
say they are not ANSI, but I will assume you mean it affects
compilation time.  I feel that ease of maintenance far outweighs
possible extra compilation time unless the penalty is egregiously
high.  You did not provide any measurements which would lead me to
believe this is the case.

	I played around with it some and found that it is not that
bad.  Depending on what include files a gcc C source file already was
including, and depending on the C source file's own size, it can take
around 3-5% longer to compile an average sized file.  (I tried adding
system.h to dbxout.c and explow.c, which at 80k and 44k respectively,
are averaged to small sized source files relative to the rest.)

	Given that the bootstrap spends a lot of time doing things
like fixincludes and running the testsuite, even if every file
included system.h, the time to do a complete bootstrap and run the
testsuite would not increase that much.

 > 
 > gcc should #define the string functions to use the ANSI names except
 > when they are known to be unavailable or undesirable.  I can't
 > remember using a system without memcpy.  It was slow on old BSD so
 > bcopy was preferred there.

	As far as the ANSI string functions go, I would tend to agree
with you that we should define in terms of the mem* forms, which we
already do currently if the b* forms are not there.  I guess you're
proposing to always do it if the mem* form are there regardless of
whether the b* ones are present.  I don't see the advantage but I'm
not particularly against it.  (Checking "unavailability" is easy,
though, I'm not sure how we determine if the ANSI forms are
"undesirable".)

	This is somewhat murky since I believe the coding standard is
to still require the old BSD style stuff should be used.  (At least I
think I read that on the gcc2 list within the last couple of months.)
I think there is a mix of ANSI and BSD style in gcc's code and it is
not consistent, ie messy.  However the current mechanism works so I'm
not in a particular hurry to break it. :-)

		--Kaveh
--
Kaveh R. Ghazi			Project Manager / Custom Development
ghazi@caip.rutgers.edu		ICon CMT Corp.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]