Re: [Qemu-devel] [PATCH] use qemu_malloc and friends consistently

[Markus Armbruster]

address@hidden writes:

[...]
> It seems to be just a fact that all malloc implementation are not
> compatible in their behavior. None of these implementations are
> necessarily wrong, but we just need to decide what is the allowed
> behavior for the qemu "platform" and then make sure that the
> qemu_malloc() implemetation is consistent on all underlying platforms.

No.  malloc() implements the same, well-known spec everywhere.  Some
people don't understand or don't like the spec, but that doesn't make
implementations of the spec incompatible.  Here's what you can expect
from malloc():

* After p = malloc(SIZE), you can access p[i] for 0 <= i < SIZE.  It
  follows that you must not dereference p at all if SIZE == 0.

* If malloc(SIZE) returns a null pointer, and SIZE != 0, then malloc()
  failed.

* Any result of malloc() can safely be passed to free().

A wrapper like qemu_malloc() can implement a different spec, of course.
But only if the spec is compatible, the wrapper can be used as a drop-in
replacement.  Making it gratuitously incompatible is foolish, because it
*breaks* code that works just fine with malloc().

We already agreed on one compatible difference: qemu_malloc() shall not
fail, but just terminate the program.

We're debating another difference, namely what qemu_malloc(0) shall do.
Two fine compatible options have been proposed here:

1. qemu_malloc(0) shall return a null pointer.

2. qemu_malloc(0) shall return a non-null pointer that can be passed to
   qemu_free()

The one that got committed is incompatible.