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

Backports commit f7c922ed3d8e3cb54febbdc594ce9f4400e0d290 from qemu
This commit is contained in:
Murilo Opsfelder Araujo 2018-05-22 00:30:39 -04:00 committed by Lioncash
parent 7e8902eccc
commit 3a3aa9e23d
No known key found for this signature in database
GPG key ID: 4E3C3CC1031BA9C7

View file

@ -100,6 +100,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.