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: egcs-19980531, warning patches [part 1/2]


   Date: Mon, 08 Jun 1998 00:20:17 -0400
   From: David Edelsohn <dje@watson.ibm.com>

	   I don't understand what Jeff's demonstration that the HPUX kernel
   does not contain the symbol calloc proves.  calloc need not be used
   specifically because it is efficient on Linux, but it seems to be the
   correct function for this intended purpose.  I don't understand why we
   should avoid it.

	   Many systems implement it as malloc/memset, which is our proposed
   implementation if it does not exist on the system.  I don't know autoconf
   very well, but even I could test for calloc and provide a default
   implementation if it didn't exist.

The calloc call lives in the target environment, and it's hard to use
autoconf to test for that.  autoconf tests for the host environment.

For what it's worth, I agree with Jeff: dependencies of gcc generated
code on the target system should be minimized.

libgcc, and gcc generated code, already depends upon memset, so simply
changing bzero to memset seems appropriate to me.

We could use an autoconf test in the particular case of a native
system.  I don't personally see speed as an issue here--it appears
that the call to malloc/bzero or calloc is made at most once per
program execution, so it really doesn't seem worth worrying about--but
that would be a way to permit the speed advantage of calloc on Linux.

Ian


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