On 5/6/21 9:22 AM, Warner Losh wrote: > On Thu, May 6, 2021 at 7:39 AM Philippe Mathieu-Daudé <philmd@xxxxxxxxxx> > wrote: > >> The ALLOCA(3) man-page mentions its "use is discouraged". >> Replace few calls by equivalent GLib malloc(). >> > > Except g_alloc and g_malloc are not at all the same, and you can't drop in > replace one with the other. > > g_alloc allocates stack space on the calling frame that's automatically > freed when the function returns. > g_malloc allocates space from the heap, and calls to it must be matched > with calls to g_free(). > > These patches don't do the latter, as far as I can tell, and so introduce > memory leaks unless there's something I've missed. You missed the g_autofree, whose job is to call g_free() on all points in the control flow where the malloc()d memory goes out of scope (equivalent in expressive power to alloca()d memory going out of scope). Although the code is arguably a bit slower (as heap manipulations are not as cheap as stack manipulations), in the long run that speed penalty is worth the safety factor (since stack manipulations under user control are inherently unsafe). -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org
