[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <i2sswvfijqylqpom47ypgw77qv4g2ibb2pnpufxom2nenhmgp2@rbnkf5sb7bzd>
Date: Fri, 27 Jun 2025 17:04:38 +0200
From: Alejandro Colomar <alx@...nel.org>
To: Florian Weimer <fweimer@...hat.com>
Cc: libc-alpha@...rceware.org, bug-gnulib@....org, musl@...ts.openwall.com,
наб <nabijaczleweli@...ijaczleweli.xyz>, Douglas McIlroy <douglas.mcilroy@...tmouth.edu>,
Paul Eggert <eggert@...ucla.edu>, Robert Seacord <rcseacord@...il.com>,
Elliott Hughes <enh@...gle.com>, Bruno Haible <bruno@...sp.org>,
JeanHeyd Meneide <phdofthehouse@...il.com>, Rich Felker <dalias@...c.org>,
Adhemerval Zanella Netto <adhemerval.zanella@...aro.org>, Joseph Myers <josmyers@...hat.com>,
Laurent Bercot <ska-dietlibc@...rnet.org>, Andreas Schwab <schwab@...e.de>, Thorsten Glaser <tg@...bsd.de>,
Eric Blake <eblake@...hat.com>, Vincent Lefevre <vincent@...c17.net>,
Mark Harris <mark.hsj@...il.com>, Collin Funk <collin.funk1@...il.com>,
Wilco Dijkstra <Wilco.Dijkstra@....com>, DJ Delorie <dj@...hat.com>,
Cristian Rodríguez <cristian@...riguez.im>, Siddhesh Poyarekar <siddhesh@...plt.org>,
Sam James <sam@...too.org>, Mark Wielaard <mark@...mp.org>,
"Maciej W. Rozycki" <macro@...hat.com>, Martin Uecker <ma.uecker@...il.com>,
Christopher Bazley <chris.bazley.wg14@...il.com>, eskil@...ession.se,
Daniel Krügler <daniel.kruegler@...glemail.com>, Kees Cook <keescook@...omium.org>,
Valdis Klētnieks <valdis.kletnieks@...edu>
Subject: Re: alx-0029r5 - Restore the traditional realloc(3) specification
Hi Florian,
On Fri, Jun 27, 2025 at 04:44:14PM +0200, Florian Weimer wrote:
> >> If you frame your proposal in terms of aligning with traditional
> >> behavior, you are inviting a discussion what the traditional behavior
> >> is. But this doesn't really matter.
> >>
> >> I'm not sure if your changes to the calloc, reallocarray are sufficient
> >> text. I assume we want full symmetry of the arguments because the
> >> argument order in existing programs is not very consistent. This
> >> requires dropping the requirement that one of the arguments is an object
> >> size (which rules out zero as a valid argument value).
> >
> > No, that doesn't rule it out.
>
> C11 says this in 6.2.6.1p2:
>
> | Except for bit-fields, objects are composed of contiguous sequences of
> | one or more bytes,
>
> And in 7.22.3.2p2:
>
> | The calloc function allocates space for an array of nmemb objects,
> | each of whose size is size.
>
> I think this requires size to be positive: it denotes an object size,
> and that is at least 1 because zero-sized objects do not exist according
> to 6.2.6.1p2.
C11 also says this:
<https://port70.net/~nsz/c/c11/n1570.html#7.22.3p1>
If the size of the space requested is zero,
the behavior is implementation-defined:
either a null pointer is returned,
or the behavior is as if the size were some nonzero value,
except that the returned pointer
shall not be used to access an object.
The size of *the space* is not the size of the object, it's the
multiplication of nmemb*size.
I think everybody agrees that glibc's calloc(3) is conforming to C11,
and it behaves like my proposal suggests.
alx@...ian:~/tmp$ cat c.c
#include <stdio.h>
#include <stdlib.h>
int
main(void)
{
printf("%p\n", calloc(0, 42));
perror("calloc(0, 42)");
printf("%p\n", calloc(42, 0));
perror("calloc(42, 0)");
printf("%p\n", calloc(0, 0));
perror("calloc(0, 0)");
}
alx@...ian:~/tmp$ gcc c.c
alx@...ian:~/tmp$ ./a.out
0x564b188332a0
calloc(0, 42): Success
0x564b188338d0
calloc(42, 0): Success
0x564b18833d00
calloc(0, 0): Success
In any case, I've improved the wording to be more explicit about it.
See alx-0029r6.
[...]
> >> From an implementation perspective, we need clarification that the
> >> allocation functions (except aligned_alloc) may reduce the alignment of
> >> the returned pointer to a power of two greater or equal to the requested
> >> size, for allocation sizes that are less than the fundamental alignment.
> >
> > I think I shouldn't include that in my proposal, as it's not necessary,
> > and may hinder it's approval.
>
> Martin says it's already there. You just need to make sure it applies
> to all zero-sized allocations, including zero-member allocations of
> larger-than-fundamental-arlignment objects with calloc.
I'm not an expert in this part, so I'd like to have more discussion
about it. I can prepare a separate paper for it, if we agree that's
what we want.
Have a lovely day!
Alex
--
<https://www.alejandro-colomar.es/>
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
