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: Rich Felker <dalias at aerifal dot cx>
- To: Will Newton <will dot newton at linaro dot org>
- Cc: "Joseph S. Myers" <joseph at codesourcery dot com>, 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 13:09:21 -0500
- 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> <Pine dot LNX dot 4 dot 64 dot 1311081339500 dot 3062 at digraph dot polyomino dot org dot uk> <CANu=DmjJPvCAQnST23r0Qztk8dNAKJmG+ete667tf5iLGp7riQ at mail dot gmail dot com>
On Fri, Nov 08, 2013 at 02:00:10PM +0000, Will Newton wrote:
> On 8 November 2013 13:42, Joseph S. Myers <firstname.lastname@example.org> wrote:
> > On Fri, 8 Nov 2013, Will Newton wrote:
> >> > 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 say document only what the standard requires, but don't add extra
> > validation - the general practice in glibc is not to make glibc slower or
> > bigger for valid code by checking for conditions that can only arise when
> > the user's call to a glibc function means undefined behavior (this is much
> > the same as not checking for NULL arguments when a function's interface
> > doesn't allow them, for example).
> At the moment we check for non-power-of-two alignments which are user
This code is required for posix_memalign anyway. It's not formally
required for memalign (which has no standard dictating its behavior),
but if glibc's memalign wants to accept non-power-of-two alignments,
the subsequent code would have to handle them correctly, and it
doesn't. I suspect historical implementations either reject or support
non-power-of-two alignments rather than blowing up, so from a
compatibility standpoint, the current behavior should be preserved