This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Enhancing malloc
- From: Will Newton <will dot newton at linaro dot org>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: "Carlos O'Donell" <carlos at redhat dot com>, Siddhesh Poyarekar <siddhesh at redhat dot com>, Ondřej Bílka <neleai at seznam dot cz>, libc-alpha <libc-alpha at sourceware dot org>
- Date: Wed, 29 May 2013 13:53:54 +0100
- Subject: Re: Enhancing malloc
- References: <CANu=Dmj34hZoWr8A5dPThv14XUmP8vTgsxFLAbJ9jTTabRPqqA at mail dot gmail dot com> <20130528123317 dot GA17360 at domone dot kolej dot mff dot cuni dot cz> <20130528125444 dot GC2145 at spoyarek dot pnq dot redhat dot com> <51A50991 dot 7010100 at redhat dot com> <CANu=DmgciQkeWfS8TBq2FVokBQXQCG2V6tmYU+9jhmfCF_9GcQ at mail dot gmail dot com> <51A5EA16 dot 3070707 at redhat dot com>
On 29 May 2013 12:44, Florian Weimer <fweimer@redhat.com> wrote:
Hi Florian,
> On 05/29/2013 09:29 AM, Will Newton wrote:
>
>> Are there specific design goals of the current code? For example, if a
>> new implementation increased memory usage but increased performance
>> would that be acceptable?
>
>
> That obviously depends on the increases. 8-)
>
> Other things to consider are fork friendliness and the impact of buffer
> overruns and double-free bugs in application programs in terms of actual
> security vulnerabilities.
What do you mean by "fork friendliness" in this context?
--
Will Newton
Toolchain Working Group, Linaro