This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH][BZ 15089] Fixes malloc_trim always trims for large padding
- From: OndÅej BÃlka <neleai at seznam dot cz>
- To: Will Newton <will dot newton at linaro dot org>
- Cc: Fernando J V da Silva <fernandojvdasilva at gmail dot com>, libc-alpha <libc-alpha at sourceware dot org>, Fernando Ferraz <fernandoperches at gmail dot com>
- Date: Wed, 20 Nov 2013 11:57:02 +0100
- Subject: Re: [PATCH][BZ 15089] Fixes malloc_trim always trims for large padding
- Authentication-results: sourceware.org; auth=none
- References: <CAEdg5wVxfYRHz2qDoJGx6vs0wSD8X334m+VX-D345+xpZxy+8w at mail dot gmail dot com> <CANu=DmhJEQkaarAp4w7zOpD8UZ=ANgvmKrgw5jVpnjrom7G4Rw at mail dot gmail dot com>
On Wed, Nov 20, 2013 at 10:28:16AM +0000, Will Newton wrote:
> On 20 November 2013 04:38, Fernando J V da Silva
> <email@example.com> wrote:
> > Hi all!
> > I'm starting learning about glibc code and I've began trying to fix
> > the bug 15089. I've put some comments on Bugzilla and I wrote a patch
> > (attached) for fixing it, based on the solution proposed by Thiago
> > Ize' comment in Bugzilla as well
> > (https://sourceware.org/bugzilla/show_bug.cgi?id=15089).
> > That solution really fixes the problem, but the systrim() code still
> > mixes some signed and unsigned operations to calculate the size used
> > to call sbrk(), which may be dangerous (and in fact caused this bug).
> > I think the most correct solution would be to refactor this function
> > for only using unsigned variables but, to be honest, I haven't tried
> > it as I'm new on that (may be someone could give me some advices about
> > it?).
> > I would be glad if someone could have some time to comment it! :-)
> Hi Fernando,
> Thanks for the patch!
> In general the ternary operator tends to be quite hard to read so in
> my opinion is best avoided outside of macros. The overflow case should
> be quite simple to handle with a return 0, e.g.:
> if (top_area <= pad)
> return 0;
> Then we can remove the whole "extra > 0" conditional below as well.
> Also you need a GNU changelog entry to accompany your change (include
> it in the commit message rather than as a patch to ChangeLog as it
> makes it easier to merge) which mentions the chnages made and the BZ
> number that is being closed (see ChangeLog for examples of this).
> Finally, and perhaps the most difficult, I think this change may need
> a copyright assignment on file to be accepted (see
Copyrigth assignment is not needed for this patch but it is better to get it in
You need copyrigth assignment once total lines that you contributed
exceed 15 lines, see