From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NGyMv-0003tt-4q for qemu-devel@nongnu.org; Sat, 05 Dec 2009 12:24:29 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NGyMq-0003pu-96 for qemu-devel@nongnu.org; Sat, 05 Dec 2009 12:24:28 -0500 Received: from [199.232.76.173] (port=33955 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NGyMq-0003pn-68 for qemu-devel@nongnu.org; Sat, 05 Dec 2009 12:24:24 -0500 Received: from mx1.redhat.com ([209.132.183.28]:40112) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NGyMq-00087y-3R for qemu-devel@nongnu.org; Sat, 05 Dec 2009 12:24:24 -0500 Message-ID: <4B1A972F.7000009@redhat.com> Date: Sat, 05 Dec 2009 19:23:59 +0200 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] Permit zero-sized qemu_malloc() & friends References: <4B193DA5.6040507@codemonkey.ws> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: malc Cc: Paul Brook , Markus Armbruster , qemu-devel@nongnu.org On 12/05/2009 07:08 PM, malc wrote: > >> What's the impact of such usage? What would improve for users if it >> were eradicated? For developers? >> >> I believe the answer the first two questions is "nothing in particular", >> and the answer to the last one is "hassle". But I'd be happy to see >> *specific* examples (code, not hand-waving) for where I'm wrong. >> >> I'm opposed to "fixing" something without a real gain, not just because >> it's work, but also because like any change it's going to introduce new >> bugs. >> >> I'm particularly critical of outlawing zero size for uses like >> malloc(N*sizeof(T). These are fairly common in our code. Having to add >> special treatment for N==0 is a trap for the unwary. Which means we'll >> never be done chasing this stuff. Moreover, the special treatment >> clutters the code, and requiring it without a clear benefit is silly. >> Show me the benefit, and I'll happily reconsider. >> >> For a specific example, let's look at the first example from my commit >> message again: load_elf32(), load_elf64() in hw/elf_ops.h. "Fix" for >> its "broken" usage of qemu_mallocz(), shot from the hip, entirely >> untested: >> > Excellent example, now consider this: > > read$ cat<< eof | gcc -x c - > #define _GNU_SOURCE > #include > #include > #include > #include > > int main (void) > { > int fd = open ("/dev/zero", 0); > int ret; > void *p = (void *) -1; > > if (fd == -1) err (1, "open"); > ret = read (fd, p, 0); > if (ret != 0) err (1, "read"); > return 0; > } > eof > read$ ./a.out > a.out: read: Bad address > > I don't see how this is relevant. Linux' read(2) may or may not be broken, but what does that have to do with breaking callers of qemu_malloc() for certain use cases? -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.