* Re: Issues in manpage memalign
[not found] <d79b505c-5b19-331c-5b25-d40adc9cc843@wanadoo.fr>
@ 2023-03-10 0:35 ` Alejandro Colomar
2023-03-10 3:02 ` DJ Delorie
2023-03-10 4:05 ` Xi Ruoyao
0 siblings, 2 replies; 5+ messages in thread
From: Alejandro Colomar @ 2023-03-10 0:35 UTC (permalink / raw)
To: Floyd, Paul, GNU C Library; +Cc: linux-man
[-- 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 --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Issues in manpage memalign
2023-03-10 0:35 ` Issues in manpage memalign Alejandro Colomar
@ 2023-03-10 3:02 ` DJ Delorie
2023-03-10 7:21 ` Paul Floyd
2023-03-10 4:05 ` Xi Ruoyao
1 sibling, 1 reply; 5+ messages in thread
From: DJ Delorie @ 2023-03-10 3:02 UTC (permalink / raw)
To: Alejandro Colomar; +Cc: pjfloyd, libc-alpha, linux-man
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Issues in manpage memalign
2023-03-10 0:35 ` Issues in manpage memalign Alejandro Colomar
2023-03-10 3:02 ` DJ Delorie
@ 2023-03-10 4:05 ` Xi Ruoyao
2023-03-10 7:15 ` Paul Floyd
1 sibling, 1 reply; 5+ messages in thread
From: Xi Ruoyao @ 2023-03-10 4:05 UTC (permalink / raw)
To: Alejandro Colomar, Floyd, Paul, GNU C Library; +Cc: linux-man
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Issues in manpage memalign
2023-03-10 4:05 ` Xi Ruoyao
@ 2023-03-10 7:15 ` Paul Floyd
0 siblings, 0 replies; 5+ messages in thread
From: Paul Floyd @ 2023-03-10 7:15 UTC (permalink / raw)
To: Xi Ruoyao, Alejandro Colomar, GNU C Library; +Cc: linux-man
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Issues in manpage memalign
2023-03-10 3:02 ` DJ Delorie
@ 2023-03-10 7:21 ` Paul Floyd
0 siblings, 0 replies; 5+ messages in thread
From: Paul Floyd @ 2023-03-10 7:21 UTC (permalink / raw)
To: DJ Delorie, Alejandro Colomar; +Cc: libc-alpha, linux-man
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
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2023-03-10 7:21 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <d79b505c-5b19-331c-5b25-d40adc9cc843@wanadoo.fr>
2023-03-10 0:35 ` Issues in manpage memalign Alejandro Colomar
2023-03-10 3:02 ` DJ Delorie
2023-03-10 7:21 ` Paul Floyd
2023-03-10 4:05 ` Xi Ruoyao
2023-03-10 7:15 ` Paul Floyd
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).