HACKING: document preference for g_new instead of g_malloc
PATCH 1/1 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
--- HACKING | 9 +++++++++ 1 file changed, 9 insertions(+)
HACKING +9 -0
@@ -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). 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 qemu_vfree, since breaking this will cause problems on Win32.
Signature · 1 line
2.14.3
Quoted 12 lines · Murilo Opsfelder Araujo
This patch documents the preference for
g_newinstead ofg_malloc. The reasons were adapted from commitb45c03f585ea9bb1af76c73e82195418c294919d.Discussion in QEMU's mailing list:
http://lists.nongnu.org/archive/html/qemu-devel/2018-05/msg03238.htmlCc David Hildenbrand <[email protected]>Cc Eduardo Habkost <[email protected]>Cc Markus Armbruster <[email protected]>Cc Paolo Bonzini <[email protected]>Signed-off-by Murilo Opsfelder Araujo <[email protected]>
Quoted 3 lines
--- HACKING | 9 +++++++++ 1 file changed, 9 insertions(+)
Signature · 3 lines
Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
Quoted 6 lines · Murilo Opsfelder Araujo
This patch documents the preference for
g_newinstead ofg_malloc. The reasons were adapted from commitb45c03f585ea9bb1af76c73e82195418c294919d.Discussion in QEMU's mailing list:
http://lists.nongnu.org/archive/html/qemu-devel/2018-05/msg03238.html
Quoted 6 lines
Cc David Hildenbrand <[email protected]>Cc Eduardo Habkost <[email protected]>Cc Markus Armbruster <[email protected]>Cc Paolo Bonzini <[email protected]>Signed-off-by Murilo Opsfelder Araujo <[email protected]>
Quoted 13 lines
--- HACKING | 9 +++++++++ 1 file changed, 9 insertions(+)HACKING +1
-0@@ -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). 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
HACKING Please note that g_malloc will exit on allocation failure, so there · line 131
Quoted 10 lines
HACKING +8
-0+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 qemu_vfree, since breaking this will cause problems on Win32.
--
Alex Bennée
adding qemu-trivial as a potential tree for this to go through
Quoted 37 lines · Murilo Opsfelder Araujo
This patch documents the preference for
g_newinstead ofg_malloc. The reasons were adapted from commitb45c03f585ea9bb1af76c73e82195418c294919d.Discussion in QEMU's mailing list:
http://lists.nongnu.org/archive/html/qemu-devel/2018-05/msg03238.htmlCc David Hildenbrand <[email protected]>Cc Eduardo Habkost <[email protected]>Cc Markus Armbruster <[email protected]>Cc Paolo Bonzini <[email protected]>Signed-off-by Murilo Opsfelder Araujo <[email protected]>--- HACKING | 9 +++++++++ 1 file changed, 9 insertions(+)HACKING +9
-0@@ -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). 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 qemu_vfree, since breaking this will cause problems on Win32.
Signature · 3 lines
Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
Quoted 21 lines · Murilo Opsfelder Araujo
This patch documents the preference for
g_newinstead ofg_malloc. The reasons were adapted from commitb45c03f585ea9bb1af76c73e82195418c294919d.Discussion in QEMU's mailing list:
http://lists.nongnu.org/archive/html/qemu-devel/2018-05/msg03238.htmlCc David Hildenbrand <[email protected]>Cc Eduardo Habkost <[email protected]>Cc Markus Armbruster <[email protected]>Cc Paolo Bonzini <[email protected]>Signed-off-by Murilo Opsfelder Araujo <[email protected]>--- HACKING | 9 +++++++++ 1 file changed, 9 insertions(+)HACKING +0
-0
HACKING Please note that g_malloc will exit on allocation failure, so there · line 122
Quoted 5 lines
HACKING +2
-0@@ -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). 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:
Should we make this stronger? s/Prefer/Use/ ? Because I think that for this use case we have an agreement (sizeof(T) vs. sizeof(*var)).
HACKING Please note that g_malloc will exit on allocation failure, so there · line 132
Quoted 11 lines
HACKING +7
-0+ + 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 qemu_vfree, since breaking this will cause problems on Win32.
This seems to be the right place to start documenting such stuff.
Signature · 3 lines
Thanks, David / dhildenb