public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Paul Eggert <eggert@cs.ucla.edu>
To: DJ Delorie <dj@redhat.com>
Cc: libc-alpha@sourceware.org,
	Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>
Subject: Re: [patch] aligned_alloc: conform to C17
Date: Thu, 16 Mar 2023 23:33:50 -0700	[thread overview]
Message-ID: <7c6b7579-e6ce-c6c4-cc97-957967849613@cs.ucla.edu> (raw)
In-Reply-To: <xno7os2qmf.fsf@greed.delorie.com>

On 2023-03-16 17:00, DJ Delorie wrote:
> Paul Eggert <eggert@cs.ucla.edu> writes:
>> powerof2 (0) == 1, unfortunately....
> _mid_memalign enforces a minimum alignment so this isn't an issue, other
> than the pedantry of whether 0 is an iso-valid alignment.

Yes, it's the pedantry I was worried about. (That's the main point of 
the patch anyway - namely, conforming to the standard.)


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

As you mention the C17 wording is not entirely clear, but it's 
implausible that the standardizers intended 0 to be a valid alignment: 
if they had intended that they would have said so clearly.

There's also a commensense argument: a pointer value aligned to A is in 
some sense a multiple of A. But the only multiple of zero is zero. So 
specifying an alignment of zero makes no intuitive sense, except perhaps 
for the all-bits-zero pointer.


> I suspect fixing the macro might be more generally useful than fixing
> this edge case

Although I haven't looked at this in detail, I suspect that changing the 
macro will merely slow other code down slightly. It might be better to 
leave the macro alone (perhaps changing its comment), and to fix just 
aligned_alloc.


  reply	other threads:[~2023-03-17  6:33 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-16 20:48 DJ Delorie
2023-03-16 21:00 ` Adhemerval Zanella Netto
2023-03-17  0:00   ` DJ Delorie
2023-03-17  6:33     ` Paul Eggert [this message]
2023-03-17 19:55       ` DJ Delorie
2023-03-16 22:00 ` Paul Eggert

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7c6b7579-e6ce-c6c4-cc97-957967849613@cs.ucla.edu \
    --to=eggert@cs.ucla.edu \
    --cc=adhemerval.zanella@linaro.org \
    --cc=dj@redhat.com \
    --cc=libc-alpha@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).