[PATCH 1/2] malloc/malloc.c: Validate SIZE passed to aligned_alloc.
Will Newton
will.newton@linaro.org
Fri Nov 8 14:00:00 GMT 2013
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. 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
More information about the Libc-alpha
mailing list