Fix calls to malloc, realloc in prefix.c

[Horst von Brand]

"Kaveh R. Ghazi" <ghazi@caip.rutgers.edu> said:
>  Horst von Brand <vonbrand@sleipnir.valparaiso.cl> said:

>  > On 20000207, a simple:
>  > 
>  >    egrep -l '\<malloc\>' $(find . -name "*.c") > /tmp/malloc.out
>  > 
>  > gives:

> I think your regexp is to general.  I would use the following:
> '\<malloc[ \t]*\(' and only in the gcc directory, and not on the
> testsuite. :-)
> 
> The results fall into these categories:
> 
> 1.  comments containing the word "malloc()".
> 2.  local implementations of xmalloc which need malloc, e.g. gen*.c
> 3.  bison generated files which call malloc, e.g. c-parse.c
> 4.  files which don't include system.h and/or don't link with libiberty.a,
>     e.g. libgcc2.c, etc.
> 5.  mistaken calls to malloc which should be xmalloc, e.g. prefix.c.
> 6.  a few cases where we *might* really need to call malloc.

OK, doing that and hacking out the testsuite leaves 115 files. 3 mention it
only in comments, a file is probably a duplicate (for
texinfo/info/echo[-_]area.[ch] all 4 exist, but the '_' variants aren't
mentioned in the Makefile.in AFAIS).

After weeding out what looks like reasonable uses of malloc(3) which are
checked, this leaves:

gcc/cppalloc.c: defines xmalloc()/xrealloc()

  Looks like that's its purpose. Why not libiberty?


gcc/genattr.c: defines xmalloc()/xrealloc()
gcc/genattrtab.c: defines xmalloc()/xrealloc()
gcc/gencheck.c: defines xmalloc()
gcc/gencodes.c: defines xmalloc()/xrealloc()
gcc/genconfig.c: defines xmalloc()/xrealloc()
gcc/genemit.c: defines xmalloc()/xrealloc()
gcc/genextract.c: defines xmalloc()/xrealloc()
gcc/genflags.c: defines xmalloc()/xrealloc()
gcc/gengenrtl.c: defines xmalloc()
gcc/genopinit.c: defines xmalloc()/xrealloc()
gcc/genoutput.c: defines xmalloc()/xrealloc()
gcc/genpeep.c: defines xmalloc()/xrealloc()
gcc/genrecog.c: defines xmalloc()/xrealloc()

   Many (all?) of these mention they should be converted to use libiberty.


gcc/doschk.c: unchecked (87, 89, 90, 91, 244)
gcc/frame.c: unchecked (272, 771, 827?, 856?)
gcc/libgcc2.c: unchecked (1976, 1988, 2318)
gcc/prefix.c: unchecked (142, 214?)
gcc/f/fini.c: unchecked (368)
libiberty/mpw.c: unchecked (184, 655, 861)
libio/floatconv.c: unchecked (414)
gcc/fixinc/gnu-regex.c: unchecked (2906); *TALLOC* macros aren't checked AFAIKS
gcc/intl/dcgettext.c: ADD_BLOCK fishy (186); define alloca, assume it works (279, 286, 307, 316)
gcc/intl/localealias.c: #define alloca(), assume it works (228); ADD_BLOCK fishy (106)

   All of the above contain what looks like legitimate uses of malloc(3),
   but the result is not checked on the calls on the lines mentioned. Very
   fishy. Some #define alloca to malloc(3), and don't check what it returns
   either... and gnu-regex seems not to check the return values of its many
   *TALLOC* macros anywhere.


gcc/f/malloc.c: assert protected in malloc_init() (143)

   This one calls malloc(3), and the only protection is an
   assert(). Doesn't look good enough to me.


gcc/config/winnt/fixinc-nt.c: unchecked (99, 100, 184, 235)
gcc/config/winnt/ld.c: unchecked (134, 222, 255, 271, 277, 334)
gcc/config/winnt/spawnv.c: unchecked (22)
gcc/fixinc/fixlib.c: unchecked (52)

   More unchecked calls, but perhaps OK, as they seem to be auxiliary
   programs? 


libchill/chillstdio.c: defines __xmalloc
libchill/rts.c: defines xmalloc()
libf2c/libI77/err.c: Only extern declaration


texinfo/info/tilde.c: defines xmalloc()/xrealloc()
texinfo/intl/dcgettext.c: #define alloca(); assume it works (276, 283, 304, 315)
texinfo/intl/localealias.c: #define alloca(); assume it works (203)
texinfo/makeinfo/makeinfo.c: malloc() not checked (9134)

> I think adding the #error to system.h would help us catch all of #5.

AFAIKS, your idea won't catch the worst of the above, i.e., uses in files
that end up in libraries. A crashing compiler sure is bad, but one that
creates executables that misteriously crash is worse IMVHO.

> Cases 1 & 4 won't be affected by a define in system.h and for 2, 3 & 6
> we can undef malloc locally.  (An alternate solution for #2 would be
> to finally generate both host & build copies of libiberty and nuke the
> local implementations of xmalloc.)

AFAIU, the gen* programs run on the build machine for the compiler, so they
could use libiberty from day one. Or am I missing something here?
-- 
Horst von Brand                             vonbrand@sleipnir.valparaiso.cl
Casilla 9G, Viña del Mar, Chile                               +56 32 672616