From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from zimbra.cs.ucla.edu (zimbra.cs.ucla.edu [131.179.128.68]) by sourceware.org (Postfix) with ESMTPS id 6FFA73851C00 for ; Fri, 17 Mar 2023 06:33:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 6FFA73851C00 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=cs.ucla.edu Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=cs.ucla.edu Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id AAB28160036; Thu, 16 Mar 2023 23:33:51 -0700 (PDT) Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id uAa3qsBrXYjQ; Thu, 16 Mar 2023 23:33:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id DFDA8160097; Thu, 16 Mar 2023 23:33:50 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.9.2 zimbra.cs.ucla.edu DFDA8160097 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.ucla.edu; s=78364E5A-2AF3-11ED-87FA-8298ECA2D365; t=1679034830; bh=Xr0pjjJLQFhhqOovNeLpcJxtGo0aOp8KG96bdlxnqxg=; h=Message-ID:Date:MIME-Version:To:From:Subject:Content-Type: Content-Transfer-Encoding; b=EMkf9Laxerr6LGIcfIDum5RXiQ8T0EMBuDSdWVOYqoW44skW+x3ms0PFjPzzThpXr pKSMLQmGQdQqCo9JqjxTpQv09v+bUMY/UMMZsDMaRSg3W4/txW+pja0nMhtJneax9L xH3Cwgz831wk0gggzj2IuDMpC5TPUlkJlEyWgkFs= X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 8E0lcJnvHEBD; Thu, 16 Mar 2023 23:33:50 -0700 (PDT) Received: from [192.168.1.9] (cpe-172-91-119-151.socal.res.rr.com [172.91.119.151]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id B174A160036; Thu, 16 Mar 2023 23:33:50 -0700 (PDT) Message-ID: <7c6b7579-e6ce-c6c4-cc97-957967849613@cs.ucla.edu> Date: Thu, 16 Mar 2023 23:33:50 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 Content-Language: en-US To: DJ Delorie Cc: libc-alpha@sourceware.org, Adhemerval Zanella Netto References: From: Paul Eggert Organization: UCLA Computer Science Department Subject: Re: [patch] aligned_alloc: conform to C17 In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,JMQ_SPF_NEUTRAL,KAM_NUMSUBJECT,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 2023-03-16 17:00, DJ Delorie wrote: > Paul Eggert 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.