From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=a9aK=7C=wanadoo.fr=pjfloyd@sourceware.org>
Received: from smtp.smtpout.orange.fr (smtp-16.smtpout.orange.fr [80.12.242.16])
	by sourceware.org (Postfix) with ESMTPS id 480F13858C54
	for <libc-alpha@sourceware.org>; Fri, 10 Mar 2023 07:15:21 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 480F13858C54
Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=wanadoo.fr
Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=wanadoo.fr
Received: from [192.168.1.28] ([90.112.30.115])
	by smtp.orange.fr with ESMTPA
	id aWyEphE40pT0waWyFpygEa; Fri, 10 Mar 2023 08:15:19 +0100
X-ME-Helo: [192.168.1.28]
X-ME-Auth: cGpmbG95ZEB3YW5hZG9vLmZy
X-ME-Date: Fri, 10 Mar 2023 08:15:19 +0100
X-ME-IP: 90.112.30.115
Message-ID: <36fa486f-1ea4-99f9-0240-4f1691cdbfde@wanadoo.fr>
Date: Fri, 10 Mar 2023 08:15:18 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.8.0
Subject: Re: Issues in manpage memalign
To: Xi Ruoyao <xry111@xry111.site>, Alejandro Colomar
 <alx.manpages@gmail.com>, GNU C Library <libc-alpha@sourceware.org>
Cc: linux-man@vger.kernel.org
References: <d79b505c-5b19-331c-5b25-d40adc9cc843@wanadoo.fr>
 <77cfc3d2-cd41-13a7-bdb9-ced179531f33@gmail.com>
 <99154d24d07cfa550a1ec4f3c5e5f5d222c7fabb.camel@xry111.site>
Content-Language: en-GB
From: Paul Floyd <pjfloyd@wanadoo.fr>
In-Reply-To: <99154d24d07cfa550a1ec4f3c5e5f5d222c7fabb.camel@xry111.site>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00,BODY_8BITS,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,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: <libc-alpha.sourceware.org>


On 10/03/2023 05:05, Xi Ruoyao wrote:
>
>>> There is a missing EINVAL description. If the alignment is so large that
>>> the allocation will not be possible to satisfy then the call will fail
>>> and set errno to EINVAL.
> POSIX says it should be ENOMEM:
>
> [ENOMEM]
> There is insufficient memory available with the requested alignment.
>
> https://pubs.opengroup.org/onlinepubs/9699919799/functions/posix_memalign.html
>
> And it seems also true with Glibc (at least Glibc-2.37):
>
> $ cat t.c
> #include <stdlib.h>
> #include <stdio.h>
>
> int main()
> {
> 	void *p;
> 	if (posix_memalign(&p, sizeof(void *) << 55, 1) != 0)
> 		perror("posix_memalign");
> }
> $ cc t.c
> $ ./a.out
> posix_memalign: Cannot allocate memory

I was referring to memalign / aligned_alloc. The ERRORS section of the 
manpage doesn't specify which errors apply to which functions.

Here is an example

#include <stdlib.h>
#include <malloc.h>

int main()
{
   void *p;
   if ((p == memalign(0xabcdef0123456789, 1)) == 0)
      perror("memalign");
}

This does satisfy

EINVAL The alignmentargument was not a power of two, or was not a 
multiple of sizeof(void*).

but that is purely a coincidence. The code in gblic that triggers the 
error is

│    3537 /* If the alignment is greater than SIZE_MAX / 2 + 1 it cannot 
be a
│    3538      power of 2 and will cause overflow in the check below.  */
│    3539 if(alignment >SIZE_MAX /2+1)
│    3540 {
│ >  3541       __set_errno (EINVAL);
│    3542 return0;
│    3543 }


If the power-of-two constraint existed this condition would be 
redundant. The next power of two greater than SIZE_MAX / 2 + 1 is 
SIZE_MAX + 1 which cannot be represented in a word.


Regards

Paul