[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#22086: 25.1.50; [PATCH] Integrate the musl hybrid malloc patch for e

From: Eli Zaretskii
Subject: bug#22086: 25.1.50; [PATCH] Integrate the musl hybrid malloc patch for elf systems
Date: Mon, 21 Dec 2015 05:44:01 +0200

> From: Paul Eggert <address@hidden>
> Date: Sun, 20 Dec 2015 14:33:22 -0800
> Cc: Rich Felker <address@hidden>, address@hidden
> The simpler approach is to remove gmalloc.c, and to use the system memory 
> allocator, i.e., to behave as if SYSTEM_MALLOC is defined on all platforms.
> We can still support hybrid malloc for Cygwin, if SYSTEM_MALLOC wouldn't work 
> on 
> Cygwin for some reason; and we can support the similar hybrid on Darwin, if 
> it's 
> still needed. But in neither approach should we override the system malloc; 
> any 
> Emacs-specific allocation function we define should be called (say) emalloc 
> instead of malloc, so that it does not conflict with the system malloc. That 
> way, we don't have to worry about name-space collisions, either at 
> compile-time 
> or at link-time.
> If I'm wrong about gmalloc.c and it is still needed on some platforms for 
> some 
> reason, we can continue to use it, but it should define emalloc etc., and not 
> attempt to override the C standard library.

Wouldn't memory allocated with emallooc conflict with uses of malloc
in the startup code?

Other than that, I'm okay with leaving gmalloc.c's allocator under a
different name.  Removing it is something we should consider

> Long ago as I recall, we really needed to override the C standard library on 
> some platforms, due to the funny way in which undumped storage was made 
> read-only. That need is obsolete, though, which should let us simplify things 
> now.

Why is it obsolete?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]