Re: [patch] aligned_alloc: conform to C17

[DJ Delorie <dj@redhat.com>]

Adhemerval Zanella Netto via Libc-alpha <libc-alpha@sourceware.org>
writes:
> Hi D.J, this patch does not build correctly [1].  Maybe you send it too soon?

Sigh, fixing...

also, it's DJ not D.J.

>> +  GLIBC_2.38 {
>> +    __libc_aligned_alloc;
>> +  }
> How is is actually used? There is no redirection in the header if -std=c17 is used,
> nor any abilist update.

aligned_alloc() used to be a weak alias to _libc_memalign but since they
now do different things, I changed it to a weak alias to
_libc_aligned_alloc.  I put the new symbol in so that it's the same as
the old symbol.

Ug, I need to update all the .abilist files too...

Paul Eggert <eggert@cs.ucla.edu> writes:
> powerof2 (0) == 1, unfortunately. Does the C standard let aligned_alloc 

_mid_memalign enforces a minimum alignment so this isn't an issue, other
than the pedantry of whether 0 is an iso-valid alignment.

I suspect fixing the macro might be more generally useful than fixing
this edge case, but I haven't looked for any potential side-effects.

As for "non-negative alignment" I assume they mean "passing a negative
number as `alignment' to aligned_alloc()", not referring to the power of
two itself.

 "Every valid alignment value shall be a nonnegative integral power of
 two."

but alignments are also to be represented by type size_t, which is
integral and unsigned, so no interpretation of "nonnegative integral
power of two" even makes sense, other than the pedantic align=zero.

The only other hint is this one:

 "The types char, ... shall have the weakest alignment requirement."

That's align=1, implying that align=0 cannot be a valid alignment.