Re: egcs mainline, more warning patches ...

[Manfred Hollstein <manfred at s-direktnet dot de>]

On Thu, 23 July 1998, 11:58:56, ghazi@caip.rutgers.edu wrote:

 >  > From: Manfred Hollstein <manfred@s-direktnet.de>
 >  > 
 >  > On Wed, 22 July 1998, 16:22:13, ghazi@caip.rutgers.edu wrote:
 >  > 
 >  >  [snip]
 >  >  > 	Perhaps it is best to never supply a prototype for
 >  >  > malloc/realloc?  If malloc/realloc are not in stdlib.h, then hope
 >  >  > sizeof(ptr)==sizeof(int) (WRT the implicit declarations returning
 >  >  > int.)
 >  > 
 >  > No, e.g. on m68k-motorola-sysv we actually _need_ such prototypes
 >  > although sizeof(ptr)==sizeof(int); the reason is the native "cc"
 >  > generates code to return normal scalar types via data register %d0 and 
 >  > pointer types via address register %a0. If you don't have a prototype, 
 >  > bad things may happen - I remember a SUID root process compiled by an
 >  > early gcc which trashed the boot disk's super block :-(
 > 
 > 	Eek. :-)
 > 
 > 
 > 
 > 
 > 
 >  >  > 	This is what the rest of gcc's source does, ie, it doesn't
 >  >  > prototype malloc/realloc.  What I did was move the existing prototype
 >  >  > closer to stdlib.h, but not providing a backup prototype might be
 >  >  > better.
 >  > 
 >  > Are you sure? Then, I guess, I/we should fix this ASAP.
 >  > manfred
 > 
 > 
 > 
 > 	Yes, I am sure.  Although configure.in checks for the prototypes
 > for malloc, realloc, calloc and free, system.h only provides a fallback
 > for free.  That's mainly because when I merged the NEED_DECLARATION_
 > stuff from various files into system.h, none of them were for the
 > allocation functions. 

Ooops...

 > 
 > 	Does m68k-motorola-sysv provide a prototype for malloc in
 > stdlib.h?  Or somewhere else?  If not, I'm curious how then are you
 > able to bootstrap without running into the %d0/%a0 problem?  Are you
 > defining __USE_FIXED_PROTOTYPES__ during the bootstrap?

It doesn't even provide a stdlib.h :-( malloc.h contains an extern
declaration, though. Yes, I'm always defining __USE_FIXED_PROTOTYPES__
on my Motorola machines. AFAIR, I got around the %d0/%a0 problem by
adding some small assembler wrapper around the problematic functions,
but that's 6 years ago.

 > 
 > 	If we were to provide fallback prototypes in system.h, I think
 > we should increase the number of headers we look in like Carlo
 > suggested.  Are there any other places to look besides malloc.h and
 > sys/malloc.h (maybe memory.h?)

Not on this particular system.

 > 
 > 	Also, what should the return type be?  Char*, void* or
 > GENERIC_PTR?  We have to be careful not to conflict with a malloc
 > prototype lurking somewhere that configure.in couldn't find, and also
 > with any fixed prototypes in case the user built with
 > __USE_FIXED_PROTOTYPES__.  (I don't know what the right answer is.)

I guess, if all the checks for HAVE_STDLIB_H, __STDC__ and the like
fail, we should fall back to providing a simple

  extern char *malloc ();

manfred