From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MgL3Z-0007rE-UJ for qemu-devel@nongnu.org; Wed, 26 Aug 2009 12:09:06 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MgL3V-0007pK-2w for qemu-devel@nongnu.org; Wed, 26 Aug 2009 12:09:05 -0400 Received: from [199.232.76.173] (port=54405 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MgL3U-0007pF-UL for qemu-devel@nongnu.org; Wed, 26 Aug 2009 12:09:01 -0400 Received: from mx1.redhat.com ([209.132.183.28]:52914) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MgL3T-0002ZK-ME for qemu-devel@nongnu.org; Wed, 26 Aug 2009 12:09:00 -0400 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id n7QG8vXn002433 for ; Wed, 26 Aug 2009 12:08:57 -0400 Message-ID: <4A955E17.60605@redhat.com> Date: Wed, 26 Aug 2009 19:08:55 +0300 From: Avi Kivity MIME-Version: 1.0 Subject: Re: Coding style, C++ compatible code (was Re: [Qemu-devel] [PATCH 02/22] eepro100: cast a void * makes no sense) References: <51486eb6860d1680c1bce45e310dcd3aae096f43.1251111439.git.quintela@redhat.com> <4A928DF0.9000106@weilnetz.de> <87tyzxnwvb.fsf@pike.pond.sub.org> <4A953E20.8080806@mail.berlios.de> <20090826155824.GA3785@1und1.de> In-Reply-To: <20090826155824.GA3785@1und1.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org On 08/26/2009 06:58 PM, Reimar D=F6ffinger wrote: > > There are additional points, having all those casts makes people used t= o > them and generally makes it much harder to spot those that are just > wrong (not that C++ does not have this issue, since basically all > conversions/uses of void* are wrong, with C they are unavoidable). > Having casts for malloc results also makes it needlessly hard to change > the type. Use > var =3D malloc(count * sizeof(*var)) > and you only need to change the declaration, add a cast and you also > have to change all places where such allocations are done. > =20 Or better, NEW() and NEW_ARRAY(). --=20 error compiling committee.c: too many arguments to function