Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <lhuzfdt40s5.fsf@oldenburg.str.redhat.com>
Date: Fri, 27 Jun 2025 18:17:14 +0200
From: Florian Weimer <fweimer@...hat.com>
To: Alejandro Colomar <alx@...nel.org>
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

* 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.

Thanks,
Florian

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.