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: x*alloc optimizations


| Michael Meissner <meissner@cygnus.com> writes:
| | This is an unneeded micro-optimization.  I would rather burn the 2-3
| | instructions for every xmalloc call than add a bunch of configure support and
| | ifdefs to complicate the code.  Especially for Canadian crosses where you can't
| | test the behavior of the runtime system.  Another problem is that when GCC
| | configured it, malloc/calloc/realloc behaved in one fashion, but when the user
| | put the binary compiler on his/her system, the system malloc in the shared
| | library now behaves differently.
|
| I admit it may not be worth it, but it can be done without
| complicating the code.  Uses of *alloc functions don't change
| at all, and the only ifdefs I added (when I did this for fileutils)
| were in the replacement lib/*alloc.c functions.  The m4 tests assume
| *alloc are broken when cross compiling.

While linux gnulibc{1,2} may or may not change the behavior of malloc, I have
witnessed this at OSF, where one revision of OSF/1 had malloc do one behavior
(crash on NULL pointer to realloc or return NULL, I forget which), and the next
revision did another behavior (return unique pointer).  I as supplier of
compiler binaries then would have my releases not work, if I built the compiler
on one revision, and had users on the other revision tried to use the
compiler.  Depending on a configure test for malloc/realloc behavior is utterly
dangerous for providers of binary software.

--
Michael Meissner, Cygnus Solutions (Massachusetts office)
4th floor, 955 Massachusetts Avenue, Cambridge, MA 02139, USA
meissner@cygnus.com,	617-354-5416 (office),	617-354-7161 (fax)



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