From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:60355)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <paolo.bonzini@gmail.com>) id 1Tb5JM-0004DJ-JQ
	for qemu-devel@nongnu.org; Wed, 21 Nov 2012 03:05:37 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <paolo.bonzini@gmail.com>) id 1Tb5JG-0007fu-VA
	for qemu-devel@nongnu.org; Wed, 21 Nov 2012 03:05:32 -0500
Received: from mail-we0-f173.google.com ([74.125.82.173]:58634)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <paolo.bonzini@gmail.com>) id 1Tb5JG-0007ep-OZ
	for qemu-devel@nongnu.org; Wed, 21 Nov 2012 03:05:26 -0500
Received: by mail-we0-f173.google.com with SMTP id z2so249229wey.4
	for <qemu-devel@nongnu.org>; Wed, 21 Nov 2012 00:05:26 -0800 (PST)
Sender: Paolo Bonzini <paolo.bonzini@gmail.com>
Message-ID: <50AC8B43.40304@redhat.com>
Date: Wed, 21 Nov 2012 09:05:23 +0100
From: Paolo Bonzini <pbonzini@redhat.com>
MIME-Version: 1.0
References: <1353404767-4495-1-git-send-email-xiawenc@linux.vnet.ibm.com>
	<1353404767-4495-6-git-send-email-xiawenc@linux.vnet.ibm.com>
	<50AB5BC5.9030605@redhat.com> <50AC469E.1060704@linux.vnet.ibm.com>
In-Reply-To: <50AC469E.1060704@linux.vnet.ibm.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH V10 5/7] libqblock type defines
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/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>
To: Wenchao Xia <xiawenc@linux.vnet.ibm.com>
Cc: kwolf@redhat.com, peter.maydell@linaro.org, aliguori@us.ibm.com, stefanha@gmail.com, qemu-devel@nongnu.org, blauwirbel@gmail.com, kraxel@redhat.com

Il 21/11/2012 04:12, Wenchao Xia ha scritto:
>>>
>>> +#define FUNC_FREE(p) g_free((p))
>>> +#define FUNC_MALLOC(size) g_malloc((size))
>>> +#define FUNC_CALLOC(nmemb, size) g_malloc0((nmemb)*(size))
>>> +#define FUNC_STRDUP(p) g_strdup((p))
>>
>> Why keep these?
> 
>   This macro make it easy to switch mem related functions if we change
> our mind in the future.

I don't like it particularly.

If you really want it, keep it, but please use g_malloc0_n for FUNC_CALLOC.

Paolo