From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MA3AD-0007Th-R3 for qemu-devel@nongnu.org; Fri, 29 May 2009 10:34:30 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MA3A7-0007SK-3i for qemu-devel@nongnu.org; Fri, 29 May 2009 10:34:27 -0400 Received: from [199.232.76.173] (port=40463 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MA3A5-0007S6-I5 for qemu-devel@nongnu.org; Fri, 29 May 2009 10:34:21 -0400 Received: from mail-bw0-f223.google.com ([209.85.218.223]:53613) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MA3A5-0006Yd-2d for qemu-devel@nongnu.org; Fri, 29 May 2009 10:34:21 -0400 Received: by bwz23 with SMTP id 23so5505650bwz.34 for ; Fri, 29 May 2009 07:34:19 -0700 (PDT) Message-ID: <4A1FF268.1050500@codemonkey.ws> Date: Fri, 29 May 2009 09:34:16 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] use qemu_malloc and friends consistently References: <200905290758.11551.jcd@tribudubois.net> <4A1FD6E2.9020006@redhat.com> <200905291407.26757.paul@codesourcery.com> In-Reply-To: <200905291407.26757.paul@codesourcery.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Brook Cc: Kevin Wolf , Jean-Christophe Dubois , qemu-devel@nongnu.org, Gerd Hoffmann Paul Brook wrote: >> For the purpose of finding broken code returning NULL is IMHO the best >> option. Although dereferencing NULL is undefined, in practice it will >> segfault in most cases so the bugs shouldn't stay unnoticed for long. >> > > The best way to find broken code is to have qemu_malloc(0) abort, and avoid > ever trying to allocate a zero size block. Returning NULL is liable to > introduce extra bugs because code often attributes special meaning to NULL > pointers. It also breaks pointer comparison. > > To some extent the answer to this question depends how much you trust your > programmers. If you assume everyone knows the C standard well and always > writes perfect code then malloc(0) is a legitimate technique, though IMHO of > fairly limited benefit. > I disagree. The wrong reason we introduced oom_check() was because we don't trust people to check returns. Why would we trust them to check size arguments especially when a lot of programmers are not going to check size arguments by convention? If we really want to fix up code, we can do so in a more benign way. Instead of aborting, let's return malloc(1) and printf a warning. Then we can fix sites without worrying about killing guests. If we only have to fixup a few sites, then yeah, we can switch to abort(). If it turns out there's a ton of these things and the code is uglier, then we can give up and just accept these semantics. Does that sound reasonable? abort()'ing on malloc(0) is going to result in some really nasty crashes that were entirely preventable in probably 99% of circumstances. Regards, Anthony Liguori > If you want maximize chances of catching accidental mistakes as early as > possible then you should have malloc(0) abort, because it probably means > someone forgot tho consider the empty case. > > Paul > > >