Re: including <stdlib.h>

Re: including <stdlib.h>

[Kaveh R. Ghazi]

 > From: John Carr <jfc@mit.edu>
 > 
 > The *config.h files I referred to are the autoconf-generated config.h,
 > hconfig.h, tconfig.h, and auto-config.h in the gcc build directory.
 > 
 > For example, in auto-config.h replace
 > 	#define HAVE_STDLIB_H 1
 > with
 > 	#include <stdlib.h>

John,

	This approach removes some of the control one might want since,
if you include auto-config.h, you are forced to include the header file
rather than being able to check a macro.  It also removes the ability of
a config/ directory file from being able to override what autoconf tells
us. 

	Another approach would be to supply a "system.h" file which
includes various headers (eg stdlib.h), provides possibly missing system
prototypes (eg bcopy) and possibly missing system macros (eg R_OK),
etc., and each gcc source file could then include this file if desired
to get default stuff.  (Or the source file could instead enumerate these
things manually if the default system.h is not appropriate.)

	I've submitted a draft version of this to Jeff, mostly copied
from the same approach used in the fileutils package.

	Hmmm, I just checked the list archive and for some reason the
file I submitted seems to have stripped all the include statements so
they appear without the file its trying to include inside <>.  Wierd... 

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

Re: including <stdlib.h>

[Robert Lipe]

> 	Another approach would be to supply a "system.h" file which
> includes various headers (eg stdlib.h), provides possibly missing system
> prototypes (eg bcopy) and possibly missing system macros (eg R_OK),
> etc., and each gcc source file could then include this file if desired
> to get default stuff.  (Or the source file could instead enumerate these
> things manually if the default system.h is not appropriate.)

This would ease maintenance costs, but would presumably cost us
something during the compilation phase becuase then everything that
includes systems.h also picks up a presumably non-small amount of header
stuff that it now gets to preprocess.  I don't know what that cost
actually is in measureable terms, and we might decide it's worth it.
I just wanted to throw it out for discussion.

Personally, if the cost is anything less than horrible, I'm inclined
to support a migration to it.

> 	Hmmm, I just checked the list archive and for some reason the
> file I submitted seems to have stripped all the include statements so
> they appear without the file its trying to include inside <>.  Wierd... 

I've noticed that on the web archives.  I assumed it was the
html-ification process not correctly replacing those characters with &lt
and &gt so as to escape them from tags.

Re: including <stdlib.h>

[Ross Smith]

Kaveh R. Ghazi wrote:
> 
> Hmmm, I just checked the list archive and for some reason the
> file I submitted seems to have stripped all the include statements so
> they appear without the file its trying to include inside [angle > brackets]. Wierd...

The list archive is returning the documents as HTML, but neglecting to
replace less-than and greater-than (and maybe ampersand too, I haven't
checked) with the appropriate entity codes.

-- 
Ross Smith ............................. < mailto:ross.smith@nz.eds.com >
Internet and New Media, EDS (New Zealand) Ltd., Wellington, New Zealand
"Isn't it interesting that the same people who laugh at science fiction
listen to weather forecasts and economists?" -- Kelvin Throop III

Re: including <stdlib.h>

[Mark Mitchell]

>>>>> "Ross" == Ross Smith <ross.smith@nz.eds.com> writes:

    Ross> Kaveh R. Ghazi wrote:
    >>  Hmmm, I just checked the list archive and for some reason the
    >> file I submitted seems to have stripped all the include
    >> statements so they appear without the file its trying to
    >> include inside [angle > brackets]. Wierd...

    Ross> The list archive is returning the documents as HTML, but
    Ross> neglecting to replace less-than and greater-than (and maybe
    Ross> ampersand too, I haven't checked) with the appropriate
    Ross> entity codes.

This is kind-of a feature.  I actually suggested doing things this way
early on because it means you can save (as source) a patch and patch
your sources with it.   If the '<' became '&lt' that wouldn't be
possible.  Perhaps the CVS server obsoletes this, but perhaps not;
it's sometimes nice to be able to try out someone's patch, or assist
them with it, before it's ready to be checked in.  Ideally, of course,
we'd have both...

    Ross> -- Ross Smith
    Ross> ............................. < mailto:ross.smith@nz.eds.com >
    Ross> Internet and New Media, EDS (New Zealand) Ltd., Wellington,
    Ross> New Zealand "Isn't it interesting that the same people who
    Ross> laugh at science fiction listen to weather forecasts and
    Ross> economists?" -- Kelvin Throop III

-- 
Mark Mitchell		mmitchell@usa.net
Stanford University	http://www.stanford.edu

HTML archives (was: Re: including <stdlib.h>)

[Ross Smith]

Mark Mitchell wrote:
> 
> >>>>> "Ross" == Ross Smith <ross.smith@nz.eds.com> writes:
> 
> Ross> The list archive is returning the documents as HTML, but
> Ross> neglecting to replace less-than and greater-than (and maybe
> Ross> ampersand too, I haven't checked) with the appropriate
> Ross> entity codes.
> 
> This is kind-of a feature.  I actually suggested doing things this way
> early on because it means you can save (as source) a patch and patch
> your sources with it.   If the '<' became '&lt' that wouldn't be
> possible.  Perhaps the CVS server obsoletes this, but perhaps not;
> it's sometimes nice to be able to try out someone's patch, or assist
> them with it, before it's ready to be checked in.  Ideally, of course,
> we'd have both...

I don't understand the problem. Netscape, and I assume any web browser,
can save a page as plain text, which converts the HTML entities back
into characters.

(Please don't mail to me as well as the list, it just means I get it
twice.)

-- 
Ross Smith ............................. < mailto:ross.smith@nz.eds.com >
Internet and New Media, EDS (New Zealand) Ltd., Wellington, New Zealand
"Isn't it interesting that the same people who laugh at science fiction
listen to weather forecasts and economists?" -- Kelvin Throop III

Re: HTML archives (was: Re: including <stdlib.h>)

[Richard Henderson]

On Fri, Feb 13, 1998 at 08:12:44AM +1300, Ross Smith wrote:
> I don't understand the problem. Netscape, and I assume any web browser,
> can save a page as plain text, which converts the HTML entities back
> into characters.

And typically messes up white space (tabs to spaces or what)
in the process, which prevent the patch from appying properly.


r~

Re: including <stdlib.h>

[Kaveh R. Ghazi]

 > From: Jeffrey A Law <law@hurl.cygnus.com>
 >  
 >   > On pre-ANSI systems, I think varargs was present on svr3.  I don't know
 >   > about older BSD.  (Did they use _doprnt?)
 >  
 > I don't think we need to worry too much about that -- 4.2BSD had varargs
 > if I remember correctly (it used _doprnt internally in the C library,
 > but I believe it still had a varargs.h include file).
 > jeff 

	The only system I ever had access to on which configure decided
to use _doprnt was an old Tektronix 4300 running a variant of BSD 4.2
called UTek 4.?.  When building meyering's *utils packages, configure
would punt down to _doprnt which was used by *utils/lib/error.c because
vprintf wasn't present.  I don't recall if varargs.h was available or
not. 

	I don't think it matters because to my knowledge gcc never
officially worked on that system, though I think an unofficial port was
floating around. 

	Other BSD 4.2 systems may or may not be an issue.  Anyone
remember what Pyramid OSx 4.x had in its BSD universe?  Hmm, maybe this
doesn't matter? :-)

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

Re: including <stdlib.h>

[Kaveh R. Ghazi]

 >   >   18 <stdarg.h>
 >   >   17 <varargs.h>
 >  
 > Odd -- that means something in the tree won't be compilable with a non
 > ANSI compiler.  Maybe its something in libgcc2 where this wouldn't be
 > an issue.
 > jeff

	I've found the following scattered all over the gcc source (eg
in calls.c):

#ifdef __STDC__
#include <stdarg.h>
#else
#include <varargs.h>
#endif

So if they're not ANSI, currently they at least need varargs.h.  On
pre-ANSI systems, I think varargs was present on svr3.  I don't know
about older BSD.  (Did they use _doprnt?)

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

Re: including <stdlib.h>

[Jeffrey A Law]

  In message < 199802121841.NAA21939@caip.rutgers.edu >you write:
  > So if they're not ANSI, currently they at least need varargs.h.
Yup.

  > On pre-ANSI systems, I think varargs was present on svr3.  I don't know
  > about older BSD.  (Did they use _doprnt?)
I don't think we need to worry too much about that -- 4.2BSD had varargs
if I remember correctly (it used _doprnt internally in the C library,
but I believe it still had a varargs.h include file).

jeff 

Re: including <stdlib.h>

[Kaveh R. Ghazi]

 > From: Robert Lipe <robertl@dgii.com>
 > 
 > > 	Another approach would be to supply a "system.h" file which
 > > includes various headers (eg stdlib.h), provides possibly missing system
 > > prototypes (eg bcopy) and possibly missing system macros (eg R_OK),
 > > etc., and each gcc source file could then include this file if desired
 > > to get default stuff.  (Or the source file could instead enumerate these
 > > things manually if the default system.h is not appropriate.)
 > 
 > This would ease maintenance costs, but would presumably cost us
 > something during the compilation phase becuase then everything that
 > includes systems.h also picks up a presumably non-small amount of header
 > stuff that it now gets to preprocess.  I don't know what that cost
 > actually is in measureable terms, and we might decide it's worth it.
 > I just wanted to throw it out for discussion.
 > 

	Yes depending on the cost, that point could be valid.  Perhaps
we only want to include the most frequently used system headers?  I
did a survey using the following shell command (get ready for a
mouthful):

  grep '^#.*include.*<' {.,cp,objc,f,config/*}/*.[ch] | sed 's/.*</</' | \
	awk '{print$1}' | sort | uniq -c | sort -nr

I've appended the results at the end of this message.  I think its
clear that we probably want "system.h" to include <stdio.h> and not
bother with <float.h>. :-) But exactly where the cutoff should be I
don't know.  Maybe we can start with what I submitted and see if it
actually affects compilation time in a noticeable way.  It turns out
that the files in my draft system.h are typically the more frequently
included by the gcc source.



 > Personally, if the cost is anything less than horrible, I'm inclined
 > to support a migration to it.


	Agreed, centralizing this stuff is a win from a maintenance
point of view.  Programmer time is at a higher premium than cpu time.


 > > 	Hmmm, I just checked the list archive and for some reason the
 > > file I submitted seems to have stripped all the include statements so
 > > they appear without the file its trying to include inside <>.  Wierd... 
 > 
 > I've noticed that on the web archives.  I assumed it was the
 > html-ification process not correctly replacing those characters with &lt
 > and &gt so as to escape them from tags.

	Ah, that makes sense.  Thanks.

		--Kaveh



 198 <stdio.h>
  64 <stdlib.h>
  56 <ctype.h>
  47 <string.h>
  30 <sys/types.h>
  26 <errno.h>
  22 <unistd.h>
  18 <stdarg.h>
  17 <varargs.h>
  16 <time.h>
  16 <strings.h>
  15 <sys/stat.h>
  14 <signal.h>
  13 <stddef.h>
  13 <setjmp.h>
  13 <limits.h>
  10 <sys/time.h>
  10 <objc/thr.h>
  10 <malloc.h>
  10 <fcntl.h>
  10 <alloca.h>
   9 <sys/param.h>
   7 <sys/file.h>
   6 <locale.h>
   5 <sys/resource.h>
   5 <stab.h>
   5 <pthread.h>
   5 <netbsd.h>
   5 <m68k/m68k.h>
   5 <i386/gstabs.h>
   4 <xm-netbsd.h>
   4 <xm-lynx.h>
   4 <xm-linux.h>
   4 <windows.h>
   4 <sys/mman.h>
   4 <sparc/sparc.h>
   4 <process.h>
   4 <lynx.h>
   4 <linux-aout.h>
   4 <inttypes.h>
   4 <i386/xm-i386.h>
   4 <dirent.h>
   4 <config.h>
   4 <a.out.h>
   3 <lynx-ng.h>
   3 <gnu-versions.h>
   2 <thread.h>
   2 <sys/wait.h>
   2 <sys/times.h>
   2 <sys/dir.h>
   2 <sparc/xm-sparc.h>
   2 <sparc/sysv4.h>
   2 <objc/objc.h>
   2 <mon.h>
   2 <math.h>
   2 <m68k/xm-m68k.h>
   2 <m68k/coff.h>
   2 <linux.h>
   2 <libintl.h>
   2 <io.h>
   2 <i386/perform.h>
   2 <gnu.h>
   2 <descrip.h>
   2 <arm/xm-arm.h>
   2 <ansidecl.h>
   1 <xm-gnu.h>
   1 <xm-freebsd.h>
   1 <unixlib.h>
   1 <ulocks.h>
   1 <syscall.h>
   1 <sys/vmparam.h>
   1 <sys/vmmac.h>
   1 <sys/varargs.h>
   1 <sys/sysmp.h>
   1 <sys/signal.h>
   1 <sys/prctl.h>
   1 <sys/m88kbcs.h>
   1 <synch.h>
   1 <syms.h>
   1 <syidef.h>
   1 <svr4.h>
   1 <string.h>
   1 <stdio.h>
   1 <stamp.h>
   1 <ssdef.h>
   1 <sgs.h>
   1 <rs6000/rs6000.h>
   1 <pcthread.h>
   1 <os2.h>
   1 <objc/typedstream.h>
   1 <ns32k/xm-ns32k.h>
   1 <ns32k/ns32k.h>
   1 <nam.h>
   1 <mips/mips.h>
   1 <machine/sysnews.h>
   1 <machine/machparam.h>
   1 <mach_o_vals.h>
   1 <mach_o_types.h>
   1 <mach_o_header.h>
   1 <mach_o_format.h>
   1 <mach/mach.h>
   1 <mach/cthreads.h>
   1 <link.h>
   1 <ldfcn.h>
   1 <i386/linux.h>
   1 <i386/i386.h>
   1 <i386/gas.h>
   1 <i386/att.h>
   1 <float.h>
   1 <fab.h>
   1 <dirent.h>
   1 <demangle.h>
   1 <dbxstclass.h>
   1 <assert.h>
   1 <ar.h>
   1 <aoutos.h>
   1 <alloc.h>
--
Kaveh R. Ghazi			Project Manager / Custom Development
ghazi@caip.rutgers.edu		ICon CMT Corp.

Re: including <stdlib.h>

[Jeffrey A Law]

  In message < 199802111722.MAA18362@caip.rutgers.edu >you write:
  > 	Agreed, centralizing this stuff is a win from a maintenance
  > point of view.  Programmer time is at a higher premium than cpu time.
Depends on how bad it gets...  I know of a Cygnus customer that has
made such a mess of their include files that it literally takes them more
than 24hrs to build their stuff -- and most of that time is spent inside
the parsing routines.  You'd be suprised how much all that useless gunk
can end up costing...

  >  198 <stdio.h>
  >   64 <stdlib.h>
  >   56 <ctype.h>
  >   47 <string.h>
  >   30 <sys/types.h>
  >   26 <errno.h>
  >   22 <unistd.h>
A datapoint -- these account for about 1/2 of the unique include files
you found.

  >   18 <stdarg.h>
  >   17 <varargs.h>
Odd -- that means something in the tree won't be compilable with a non
ANSI compiler.  Maybe its something in libgcc2 where this wouldn't be
an issue.

jeff

including <stdlib.h>

[John Carr]

Since almost every part of the compiler needs <stdlib.h>, for the
abort prototype if nothing else, it should be included by *config.h
instead of individual files.

Re: including <stdlib.h>

[Robert Lipe]

> Since almost every part of the compiler needs <stdlib.h>, for the
> abort prototype if nothing else, it should be included by *config.h
> instead of individual files.

There are everal things that are crying out for global headers - for
example our protos for error().   Certainly, this approach would also
help contain ugliness like we talked about recently with the collisions
of <string.h> & <strings.h>.

I don't see a really obvious candidate in gcc/*config.h.   Can you be
more specific in your recommendation?   Is there an existing file you're
thinking of?

RJL

Re: including <stdlib.h>

[John Carr]

The *config.h files I referred to are the autoconf-generated config.h,
hconfig.h, tconfig.h, and auto-config.h in the gcc build directory.

For example, in auto-config.h replace
	#define HAVE_STDLIB_H 1
with
	#include <stdlib.h>

Re: including <stdlib.h>

[Jeffrey A Law]

  In message < 199802111223.HAA06671@contents-vnder-pressvre.MIT.EDU >you write:
  > 
  > Since almost every part of the compiler needs <stdlib.h>, for the
  > abort prototype if nothing else, it should be included by *config.h
  > instead of individual files.
Kaveh has a patch which probably handles this for us; I need to take
a look at it (tonight if possible).  I think the basic idea is an
include file where we put all this common junk.  Preferably a 
non-generated file :-)

jeff