This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]
Other format:	[Raw text]

Re: [PATCH] malloc: Always call memcpy in _int_realloc [BZ #24027]

From: Siddhesh Poyarekar <siddhesh at gotplt dot org>
To: Niklas Hambüchen <mail at nh2 dot me>, Florian Weimer <fw at deneb dot enyo dot de>, libc-alpha at sourceware dot org
Date: Thu, 27 Dec 2018 07:25:47 +0530
Subject: Re: [PATCH] malloc: Always call memcpy in _int_realloc [BZ #24027]
References: <87sgyluz8t.fsf@mid.deneb.enyo.de> <9a126d8c-2315-f92f-ad4f-ea2dd6441d8e@nh2.me>

On 26/12/18 2:25 AM, Niklas Hambüchen wrote:

Would it not make sense to first apply the patch I provided in

   https://sourceware.org/bugzilla/show_bug.cgi?id=24027

that fixes the type, and then do the removal of the memcpy special case as a refactoring?

That would ensure that if somebody disagrees with the performance-critical bit in the future and reverts this, they don't revert back to the bugged version.
It would also make it possible for downstream distributions to cherry-pick a minimal patch from upstream.

I agree with your point about reverting buggy behaviour and I'vesuggested adding a note in the commit to guard against that.

It is Florian's discretion if he wants to split this into two commitslike you suggest; it's not strictly necessary IMO (performance impactand revert risk are negligible and Florian's patch is also minimalenough for most distros) but is not that big a deal to do either.


Thanks,
Siddhesh

References:
- [PATCH] malloc: Always call memcpy in _int_realloc [BZ #24027]
  - From: Florian Weimer
- Re: [PATCH] malloc: Always call memcpy in _int_realloc [BZ #24027]
  - From: Niklas Hambüchen

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