On 04/02/2015 01:34 PM, Joseph Myers wrote:
> On Thu, 2 Apr 2015, Florian Weimer wrote:
> 
>> On 04/02/2015 01:06 PM, H.J. Lu wrote:
>>> On Thu, Apr 2, 2015 at 1:46 AM, Florian Weimer <fwei...@redhat.com> wrote:
>>>> On 04/02/2015 10:40 AM, Andrew Haley wrote:
>>>>
>>>>> So, max_align_t is an object type, and therefore malloc returns a
>>>>> pointer suitable for max_align_t.
>>>>
>>>> Then the GCC definition of max_align_t is incorrect, it should be 8 on
>>>> x86_64 GNU/Linux, because traditionally, that's what mallocs implement
>>>> for this architecture.  (dlmalloc in glibc is an exception.)
>>>>
>>>
>>> x86-64 psABI specifies that a memory >= 16 bytes is 16-byte aligned.
>>> If malloc doesn't do it, it is a broken.
>>
>> My concern is different.  I think _Alignof (max_align_t) == 16 (as it is
>> in GCC now) implies that malloc return values for sizes less than 16
>> bytes are 16-byte-aligned, too, which is not required by the x86-64 psABI.
> 
> Right back to C90 (DR#075), malloc of any size has been required to return 
> a pointer suitably aligned for all types that can be defined in C90 (such 
> as long double).  ABIs can only be understood in conjunction with the 
> language standard requirements.  If malloc fails to return memory suitably 
> aligned for long double, that's a malloc bug.

sizeof (long double) is 16 on x86_64, and malloc (16) is 16-byte-aligned
with jemalloc and tcmalloc.  This means that there is no problem in
practice.

But it is dubious to require that, say, strdup ("example") returns a
pointer which is 16-byte-aligned, too.

What is missing, it seems to me, is the qualification that for the
pointer returned by malloc, the alignment requirements only of those
types whose size does not exceed the malloc argument argument need to be
considered.

-- 
Florian Weimer / Red Hat Product Security

Reply via email to