[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <jblv5rszcm36h3imw4t4sffgrqjutjj2znbeb5kiil53ria65o@5ry6vn5cjhg3>
Date: Fri, 27 Jun 2025 19:11:45 +0200
From: Alejandro Colomar <alx@...nel.org>
To: Florian Weimer <fweimer@...hat.com>,
Joseph Myers <josmyers@...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>, 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, Joseph,
On Fri, Jun 27, 2025 at 06:17:14PM +0200, Florian Weimer wrote:
> * Alejandro Colomar:
>
> > 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.
>
> I think the wording still allows calloc (42, 0) to fail with EINVAL (or
> some other error code) because 0 is not a valid object size.
7.25.4.1 Memory management functions :: General
@@ p1
...
-If the size of the space requested is zero,
+If the total size of the space requested is zero,
-the behavior is implementation-defined:
-either
-a null pointer is returned to indicate the error,
-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.
That paragraph makes it very explicit what to do when the total size is
zero, which is the case with calloc(42,0).
Joseph, would you mind reviewing this?
Have a lovely day!
Alex
--
<https://www.alejandro-colomar.es/>
Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)
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.
