From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1MA3M4-0003Ww-CH
	for qemu-devel@nongnu.org; Fri, 29 May 2009 10:46:44 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1MA3Lx-0003UJ-6f
	for qemu-devel@nongnu.org; Fri, 29 May 2009 10:46:41 -0400
Received: from [199.232.76.173] (port=33873 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1MA3Lw-0003Tz-A7
	for qemu-devel@nongnu.org; Fri, 29 May 2009 10:46:36 -0400
Received: from srv-05.w4a.fr ([94.23.5.116]:58488 helo=mx1.w4a.fr)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <jcd@tribudubois.net>) id 1MA3Lv-0001IU-Pc
	for qemu-devel@nongnu.org; Fri, 29 May 2009 10:46:36 -0400
Date: Fri, 29 May 2009 15:46:29 +0100 (GMT+01:00)
From: jcd@tribudubois.net
Message-ID: <20950421.69461243608388968.JavaMail.root@srv-05.w4a.fr>
In-Reply-To: <28912134.69441243608238156.JavaMail.root@srv-05.w4a.fr>
Subject: Re: [Qemu-devel] [PATCH] use qemu_malloc and friends consistently
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Glauber Costa <glommer@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>, Paul Brook <paul@codesourcery.com>, qemu-devel@nongnu.org, Gerd Hoffmann <kraxel@redhat.com>


----- "Glauber Costa" <glommer@redhat.com> a =C3=A9crit :

> If we have to start programming like this because we don't trust our
> programmers,
> (ultimately, ourselves), then we're pretty much doomed.

This is not that bad:=20

It is just like having a "coding rule" on the qemu project stating that mal=
loc(0) is forbiden (even if legal) and BTW it is also enforced in the qemu_=
malloc() implementation that should always be used.

OTOH if we believe all the contributed code (past, present and furure) is a=
lways perfect then the all qemu_malloc/qemu_free ... scheme can just be dis=
carded (it adds to the complexity and decreases perf) and we go back to pla=
in malloc/free trusting the programmer to know about the subtle platform di=
fferences.

> If anyone is contributing code to qemu these days, chances are that
> his code will
> get reviewed. We'll then spot those things and kick them out. That's
> the only=20
> reasonable way to get quality.

Reviews are good and still needed but it doesn't hurt to also have some too=
ls to catch corner cases that can be easily missed.