HACKING: document preference for g_new instead of g_malloc

This patch documents the preference for g_new instead of g_malloc. The
reasons were adapted from commit b45c03f585ea9bb1af76c73e82195418c294919d.

Discussion in QEMU's mailing list:
  http://lists.nongnu.org/archive/html/qemu-devel/2018-05/msg03238.html

Cc: qemu-devel@nongnu.org
Cc: David Hildenbrand <david@redhat.com>
Cc: Eduardo Habkost <ehabkost@redhat.com>
Cc: Markus Armbruster <armbru@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Murilo Opsfelder Araujo <muriloo@linux.ibm.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
This commit is contained in:
Murilo Opsfelder Araujo 2018-05-15 10:49:50 -03:00 committed by Michael Tokarev
parent 0b816e986d
commit f7c922ed3d

View File

@ -118,6 +118,15 @@ Please note that g_malloc will exit on allocation failure, so there
is no need to test for failure (as you would have to with malloc). is no need to test for failure (as you would have to with malloc).
Calling g_malloc with a zero size is valid and will return NULL. Calling g_malloc with a zero size is valid and will return NULL.
Prefer g_new(T, n) instead of g_malloc(sizeof(T) * n) for the following
reasons:
a. It catches multiplication overflowing size_t;
b. It returns T * instead of void *, letting compiler catch more type
errors.
Declarations like T *v = g_malloc(sizeof(*v)) are acceptable, though.
Memory allocated by qemu_memalign or qemu_blockalign must be freed with Memory allocated by qemu_memalign or qemu_blockalign must be freed with
qemu_vfree, since breaking this will cause problems on Win32. qemu_vfree, since breaking this will cause problems on Win32.