This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH 1/2] malloc/malloc.c: Validate SIZE passed to aligned_alloc.
- From: OndÅej BÃlka <neleai at seznam dot cz>
- To: Will Newton <will dot newton at linaro dot org>
- Cc: Rich Felker <dalias at aerifal dot cx>, Paul Eggert <eggert at cs dot ucla dot edu>, libc-alpha <libc-alpha at sourceware dot org>, Patch Tracking <patches at linaro dot org>
- Date: Fri, 8 Nov 2013 11:30:10 +0100
- Subject: Re: [PATCH 1/2] malloc/malloc.c: Validate SIZE passed to aligned_alloc.
- Authentication-results: sourceware.org; auth=none
- References: <527BD0C3 dot 4010607 at linaro dot org> <527BD28B dot 8090407 at cs dot ucla dot edu> <CANu=DmhAmKCaTyuF0MY9CK_HBCOvN=yzgTtaKTPppghxNStWrw at mail dot gmail dot com> <20131108042055 dot GZ24286 at brightrain dot aerifal dot cx> <CANu=DmjZxxt2E8B=bjrBS7OwW+MdT6Jc6CEwf80WRAt5nPZ6FQ at mail dot gmail dot com>
On Fri, Nov 08, 2013 at 10:20:29AM +0000, Will Newton wrote:
> On 8 November 2013 04:20, Rich Felker <email@example.com> wrote:
> > On Thu, Nov 07, 2013 at 08:09:24PM +0000, Will Newton wrote:
> >> On 7 November 2013 17:48, Paul Eggert <firstname.lastname@example.org> wrote:
> >> > On 11/07/2013 09:41 AM, Will Newton wrote:
> >> >> The ISO C11 standard specifies that a SIZE passed to aligned_alloc
> >> >> must be a multiple of ALIGNMENT. Aliasing aligned_alloc to memalign
> >> >> does not enforce this restriction, so create a new function that
> >> >> does this validation.
> >> >
> >> > This doesn't look right. See the NEWS file's entry for glibc 2.16, which says:
> >> >
> >> > + aligned_alloc. NB: The code is deliberately allows the size parameter
> >> > to not be a multiple of the alignment. This is a moronic requirement
> >> > in the standard but it is only a requirement on the caller, not the
> >> > implementation.
> >> I disagree with Drepper on this point. If we don't enforce the
> >> contract on callers then it becomes possible for callers to write
> >> non-portable code with glibc aligned_alloc. Admittedly the spec of
> >> aligned_alloc isn't amazingly rigid so writing non-portable code is
> >> possible anyway, but I still think it is worth glibc validating what
> >> is actually written in the spec. If we want to write a function that
> >> implements "almost aligned_alloc" it should really be called something
> >> else IMO.
> > I'm against unnecessary and (mildly) expensive validation of a
> > condition that the implementation is not required to validate and for
> > which the check has no purpose except for intentionally breaking
> > non-portable code.
> My initial interest in this came from documenting the aligned_alloc
> interface. So should we document this non-standard behaviour?
I would call this implementation detail, so adding comment in
aligned_alloc code is appropriate, in user documentation you risk that
users will start using this behaviour.
I would be also ok if we changed behaviour to rounding size up to nearest