Re: Issues in manpage memalign

Re: Issues in manpage memalign

[Alejandro Colomar]

[-- Attachment #1.1: Type: text/plain, Size: 1975 bytes --]

Hi Paul,

On 3/7/23 23:24, Floyd, Paul wrote:
> Hi
> 
> Quick bit of background. I'm a Valgrind maintainer and recently I've 
> been working on getting Valgrind to work more like the underlying OS / 
> libc implementations of memalign, posix_memalign and aligned_alloc.
> 
> There are several issues with the manpage for memalign and aligned alloc.
> 
> quote:
> 
>         The  obsolete  function  memalign()  allocates size bytes and 
> returns a
>         pointer to the allocated memory.  The memory address will be a 
> multiple
>         of alignment, which must be a power of two.
> 
> endquote:
> 
> The power if two requirement is false for glibc which silently bumps up 
> the alignment to the next power of two.
> 
> quote:
> 
>         The  function aligned_alloc() is the same as memalign(), except 
> for the
>         added restriction that size should be a multiple of alignment.
> 
> endquote:
> 
> This is also false for glibc. In the glibc implementation weak aliases 
> are used so memalign and aligned_alloc call the same function.
> 
> quote:
> 
> ERRORS
>         EINVAL The alignment argument was not a power of two, or was not 
> a mul-
>                tiple of sizeof(void *).
> 
> endquote:
> 
> Both of the above only apply to posix_memalign and not to either 
> memalign or aligned_alloc.
> 
> 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.

I've CCd glibc, in case someone there can confirm in which direction they
would like the manual page to go.

For now, I'll add a [[deprecated]] attribute in the Synopsis for the
obsolete functions.

Cheers,

Alex

> 
> 
> Regards
> 
> Paul
> 
> 

-- 
<http://www.alejandro-colomar.es/>
GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Issues in manpage memalign

[DJ Delorie]

Alejandro Colomar via Libc-alpha <libc-alpha@sourceware.org> writes:
> I've CCd glibc, in case someone there can confirm in which direction they
> would like the manual page to go.

see https://sourceware.org/bugzilla/show_bug.cgi?id=20137
and https://sourceware.org/pipermail/libc-alpha/2023-February/145858.html

I've got this on my to-do list to fix aligned_alloc to conform to,
probably, C17.  I'll send an update for the man page when I update the
code, if you don't do it first ;-)

I don't know of any discussions to change our stance on memalign() at
this time.

Re: Issues in manpage memalign

[Paul Floyd]

On 10/03/2023 04:02, DJ Delorie wrote:
> Alejandro Colomar via Libc-alpha <libc-alpha@sourceware.org> writes:
>> I've CCd glibc, in case someone there can confirm in which direction they
>> would like the manual page to go.
> see https://sourceware.org/bugzilla/show_bug.cgi?id=20137
> and https://sourceware.org/pipermail/libc-alpha/2023-February/145858.html
>
> I've got this on my to-do list to fix aligned_alloc to conform to,
> probably, C17.  I'll send an update for the man page when I update the
> code, if you don't do it first ;-)
>
> I don't know of any discussions to change our stance on memalign() at
> this time.

Hi

Thanks for the links.

I don't see any need to change memalign since it's non-standard.


Regards

Paul

Re: Issues in manpage memalign

[Xi Ruoyao]

On Fri, 2023-03-10 at 01:35 +0100, Alejandro Colomar via Libc-alpha wrote:
> Hi Paul,
> 
> On 3/7/23 23:24, Floyd, Paul wrote:
> > Hi
> > 
> > Quick bit of background. I'm a Valgrind maintainer and recently I've
> > been working on getting Valgrind to work more like the underlying OS / 
> > libc implementations of memalign, posix_memalign and aligned_alloc.
> > 
> > There are several issues with the manpage for memalign and aligned alloc.
> > 
> > quote:
> > 
> >         The  obsolete  function  memalign()  allocates size bytes and 
> > returns a
> >         pointer to the allocated memory.  The memory address will be a 
> > multiple
> >         of alignment, which must be a power of two.
> > 
> > endquote:
> > 
> > The power if two requirement is false for glibc which silently bumps up 
> > the alignment to the next power of two.
> > 
> > quote:
> > 
> >         The  function aligned_alloc() is the same as memalign(), except 
> > for the
> >         added restriction that size should be a multiple of alignment.
> > 
> > endquote:
> > 
> > This is also false for glibc. In the glibc implementation weak aliases 
> > are used so memalign and aligned_alloc call the same function.

aligned_alloc is in C99, it says (7.22.3.1p2):

"The value of alignment shall be a valid alignment supported by the
implementation and the value of size shall be an integral multiple of
alignment."

In the context of the C standard, "shall" means (section 4 p2):

"If a "shall" or "shall not" requirement that appears outside of a
constraint or runtime-constraint is violated, the behavior is
undefined."

"It seems working" is one of the legal consequences of an undefined
behavior.  "shall" does NOT mean "if you don't obey, the implementation
is required to give some errno to you".

> > quote:
> > 
> > ERRORS
> >         EINVAL The alignment argument was not a power of two, or was not 
> > a mul-
> >                tiple of sizeof(void *).
> > 
> > endquote:
> > 
> > Both of the above only apply to posix_memalign and not to either 
> > memalign or aligned_alloc.
> > 
> > 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 have no idea about memalign() (without posix_) though.


-- 
Xi Ruoyao <xry111@xry111.site>
School of Aerospace Science and Technology, Xidian University

Re: Issues in manpage memalign

[Paul Floyd]

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