From mboxrd@z Thu Jan  1 00:00:00 1970
From: malc <av1474@comtv.ru>
Subject: Re: [PATCH] Introduce QEMU_NEW()
Date: Mon, 25 Jul 2011 18:47:04 +0400 (MSD)
Message-ID: <alpine.LNX.2.00.1107251846460.3519@linmac>
References: <1311583872-362-1-git-send-email-avi@redhat.com>
	<4E2D5D7C.40208@codemonkey.ws> <4E2D5F0D.2040303@redhat.com>
	<4E2D5FB3.7000906@codemonkey.ws>
	<CAAu8pHs_cx5GzNO2J=ZRf7QBTQ1qKratc-f8VxuRQSnrQ8Pb0g@mail.gmail.com>
	<4E2D7CD7.1060707@codemonkey.ws>
	<CAMo8BfK68QDj+4=oViGBOd3Suqqg=ndFXAkAH_GazeDNC_oDXA@mail.gmail.com>
	<4E2D810E.3060104@codemonkey.ws>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Cc: Blue Swirl <blauwirbel@gmail.com>, Max Filippov <jcmvbkbc@gmail.com>,
	Avi Kivity <avi@redhat.com>, kvm@vger.kernel.org, qemu-devel@nongnu.org
To: Anthony Liguori <anthony@codemonkey.ws>
Return-path: <qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org>
In-Reply-To: <4E2D810E.3060104@codemonkey.ws>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: </archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org
Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org
List-Id: kvm.vger.kernel.org

On Mon, 25 Jul 2011, Anthony Liguori wrote:

> On 07/25/2011 09:30 AM, Max Filippov wrote:
> > > > > > > > qemu_malloc() is type-unsafe as it returns a void pointer.
> > > > > > > > Introduce
> > > > > > > > QEMU_NEW() (and QEMU_NEWZ()), which return the correct type.
> > > > > > > 
> > > > > > > Just use g_new() and g_new0()
> > > > > > > 
> > > > > > 
> > > > > > These bypass qemu_malloc(). Are we okay with that?
> > > > > 
> > > > > Yes.  We can just make qemu_malloc use g_malloc.
> > > > 
> > > > It would be also possible to make g_malloc() use qemu_malloc(). That
> > > > way we could keep the tracepoints which would lose their value with
> > > > g_malloc() otherwise.
> > > 
> > > Or just add tracepoints to g_malloc()...
> > > 
> > > But yeah, the point is, we ought to unify to a standard library function
> > > instead of inventing our own version of everything.
> > 
> > What about zero-size allocations for which g_malloc would return NULL?
> 
> Using a standard, well documented, rich interface trumps any arguments about
> the semantics of zero-sized allocation.

Right right.. only g_new aborts on zero..

-- 
mailto:av1474@comtv.ru