Avi Kivity wrote:
A zero-supporting qemu_malloc() is fully compatible with malloc(), we're only restricting the possible returns. So we're not misleading any caller. In fact, taking your argument to the extreme, a malloc implementation would need to
This is really the crux of the whole argument. You're arguing that while most people rely on incorrect idioms with malloc(), the problem is not the idioms themselves but the definition of malloc(). The opposing argument is that instead of providing a "fixed" version of malloc(), we should encourage people to use a proper idiom.
I dislike the entire notion of qemu_malloc(). I've always disliked the fact that it abort()s on OOM. I'd rather see us use a normal malloc() and code to that malloc currently which means avoiding size=0 and checking NULL results.
However, this is all personal preference and I'd rather focus my energy on things that have true functional impact. Markus raised a valid functional problem with the current implementation and I proposed a solution that would address that functional problem. I'd rather see the discussion focus on the merits of that solution than revisiting whether ANSI got the semantics of malloc() correct in the standards definition.
Regards, Anthony Liguori
