This is the mail archive of the 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 8 November 2013 13:42, Joseph S. Myers <> 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. aligned_alloc will return NULL with EINVAL in this case, but
not in the case of size not being a multiple of alignment. It seems
awkward to document that aligned_alloc returns error and EINVAL for
one case without explicitly pointing out that it doesn't for the other
(after specifying that aligned_alloc has this requirement).

If the docs are ok as is then I'll drop this patch and respin a test
patch without the requirement to test for this case.

Will Newton
Toolchain Working Group, Linaro

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