system.h

system.h

[John Carr]

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.

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.

Re: system.h

[Jeffrey A Law]

  In message < 199802161933.OAA03190@caip.rutgers.edu >you write:
  > 	Maybe a good compromise is to split it into two files,
  > system.h and system2.h.  One contains very common stuff, the other
  > contains the rest.  I'd like to hear more opinions and try to reach a
  > consensus.
I'd prefer to have a single system.h.

If sys/stat.h is a problem, then we don't use it.

It shouldn't really be needed, except for a few files.

jeff

Re: system.h

[Kaveh R. Ghazi]

 > From: John Carr <jfc@MIT.EDU>
 > 
 > > 	Maybe a good compromise is to split it into two files,
 > > system.h and system2.h. 
 > 
 > That's better than testing a macro.  I suggest different calling the
 > files ansi.h and system.h (corresponding, more or less, to ANSI and
 > POSIX interfaces).

John,

	I don't know what particular system headers fall under the ANSI
category, but I'd rather base the primary includes on which ones are the
most requested by the egcs source, rather than which ones ANSI happens
to say are part of its spec.  (They may happily coincide, But for this
reason I would shy away from calling the primary one ansi.h.)

	If we don't based it on popularity, it'll be more likely we'll
get into the situation where too many source files include both common
headers.  Then we've gained nothing by splitting them. 

	I'd like it if you would make a proposal of which headers you
would like to see in the primary common egcs header.  I'm sure we can
reach a good compromise. 

	The following are the top ten system headers requested by the
egcs source code.  I browsed the remaining implicit function declaration
warnings, stdlib.h and string.h would seem to be the ones which would
get included a bit more, but this remains a good point of reference. 

		--Kaveh

 196 <stdio.h>
  87 <stdlib.h>
  56 <ctype.h>
  55 <string.h>
  31 <sys/types.h>
  27 <unistd.h>
  27 <errno.h>
  24 <strings.h>
  18 <time.h>
  18 <stdarg.h>

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

Re: system.h

[Kaveh R. Ghazi]

 > From: John Carr <jfc@mit.edu>
 > 
 > > 	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.
 > 
 > In my experience #including everything leads to trouble.
 > 
 > The ANSI C files are mostly harmless, but more importantly they are
 > necessary.  The others are neither harmless nor necessary in most
 > cases.
 > 
 > Here is an example: on x86 SVR4 systems <sys/stat.h> defines several
 > static functions.

	Well, I guess that could add some code bloat.  Have you done
any measurements to see if this is a serious problem or not?  Ie, does
it potentially increase the size of cc1 by 0.001%, 1%, 5%?  I'm not
wedded to the idea of including stat.h, but I'd like to know how
serious the problem is before we toss particular system includes
overboard.  If it turns out to add significantly to the size of the
compiler executable, let's jettison it.

	I'm sort of sheepishly thinking to myself there are a couple of
headers I'd like to *add* to system.h, like maybe stddef.h (??) and more
definitely stdarg.h/varargs.h. 

	Maybe a good compromise is to split it into two files,
system.h and system2.h.  One contains very common stuff, the other
contains the rest.  I'd like to hear more opinions and try to reach a
consensus.

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

Re: system.h

[John Carr]

>  > Here is an example: on x86 SVR4 systems <sys/stat.h> defines several
>  > static functions.
> 
> does it potentially increase the size of cc1 by 0.001%, 1%, 5%?

About 1-2% in this case.

> 	Maybe a good compromise is to split it into two files,
> system.h and system2.h. 

That's better than testing a macro.  I suggest different calling the
files ansi.h and system.h (corresponding, more or less, to ANSI and
POSIX interfaces).

Re: system.h

[John Carr]

> 	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.

In my experience #including everything leads to trouble.

The ANSI C files are mostly harmless, but more importantly they are
necessary.  The others are neither harmless nor necessary in most
cases.

Here is an example: on x86 SVR4 systems <sys/stat.h> defines several
static functions.

I don't see a maintenance problem in adding one or a few macro tests
to system.h surrounding the rarely needed include files.

[re #define bcopy memcpy]
> 	This is somewhat murky since I believe the coding standard is
> to still require the old BSD style stuff should be used.

I'm not proposing changing the source yet.  In the source files bcopy
and friends would still be used until gcc is converted to ANSI C.
Most modern compilers (including gcc) know about the builtin ANSI
functions and should be given the chance to use their knowledge.

Re: system.h

[Kaveh R. Ghazi]

 > 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.