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@debian:~/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@debian:~/tmp$ gcc c.c
> > alx@debian:~/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/>
signature.asc
Description: PGP signature
