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 1/2] malloc/malloc.c: Validate SIZE passed to aligned_alloc.


On Fri, Nov 08, 2013 at 02:00:10PM +0000, Will Newton wrote:
> On 8 November 2013 13:42, Joseph S. Myers <joseph@codesourcery.com> 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
> error.

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
anyway.

Rich


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