simplify GNU Emacs builds by replacing malloc

simplify GNU Emacs builds by replacing malloc

[Paul Eggert]

In Bug#27416 I propose replacing Emacs's hybrid malloc implementation on GNUish 
platforms with a hybrid implementation that redefines malloc instead of 
re-#defining it. That is, instead of defining a function hybrid_malloc that can 
call either gmalloc or the system malloc (and using the macro "#define malloc 
hybrid_malloc" in Emacs code), Emacs defines a function malloc that can call 
either gmalloc or the system malloc (via the latter’s alternate name 
‘__libc_malloc’), without using a macro.

Under this proposal, the Emacs build process no longer needs to compile library 
files twice. For example, it can simply build lib/gettime.o from lib/gettime.c, 
rather than having to build both lib/gettime.o and lib/e-gettime.o. This is 
because there is only one malloc symbol used by Emacs code, not two.

The hybrid malloc approach would not change on non-GNUish platforms.

Although this change seems like an obvious win in that it should make Emacs a 
bit easier to build and debug, I’m mentioning it on emacs-devel first in case 
anyone sees a problem with it.

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=27416

Re: simplify GNU Emacs builds by replacing malloc

[John Wiegley]

>>>>> "PE" == Paul Eggert <eggert@cs.ucla.edu> writes:

PE> The hybrid malloc approach would not change on non-GNUish platforms.

PE> Although this change seems like an obvious win in that it should make
PE> Emacs a bit easier to build and debug, I’m mentioning it on emacs-devel
PE> first in case anyone sees a problem with it.

Was there any particular reason for the macro approach?

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: simplify GNU Emacs builds by replacing malloc

[Paul Eggert]

On 06/21/2017 11:29 PM, John Wiegley wrote:
> Was there any particular reason for the macro approach?


Which macro approach, the approach currently in Emacs, or the approach 
proposed in Bug#27416? If the former, we have to be careful about 
redefining the malloc function, as this has undefined behavior in C; 
this is why Emacs #defines malloc instead. If the latter, it's a longer 
story but that approach didn't work and the proposal has been withdrawn, 
so I'm not sure it's worth taking the time to explain.

Re: simplify GNU Emacs builds by replacing malloc

[John Wiegley]

>>>>> "PE" == Paul Eggert <eggert@cs.ucla.edu> writes:

PE> On 06/21/2017 11:29 PM, John Wiegley wrote:
>> Was there any particular reason for the macro approach?

PE> Which macro approach, the approach currently in Emacs, or the approach
PE> proposed in Bug#27416? If the former, we have to be careful about
PE> redefining the malloc function, as this has undefined behavior in C; this
PE> is why Emacs #defines malloc instead. If the latter, it's a longer story
PE> but that approach didn't work and the proposal has been withdrawn, so I'm
PE> not sure it's worth taking the time to explain.

I meant the former, thanks for the clarification.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2