Paul Eggert wrote:
> Come to think of it, why do we have both malloc-gnu and malloc-posix 
> modules (and similarly for calloc and realloc)?

Package owners had two decisions to make:
  "Does my package ever call malloc (0)? - If yes, I need 'malloc-gnu'."
  "Does my package attempt portability to native Windows? - If yes, I
   need 'malloc-posix'."

> In other words, I suggest that we remove malloc-posix, realloc-posix and 
> calloc-posix

Think about the effects on the package on non-glibc platforms, from the
perspective of the package owner.
For example, if my package never calls malloc (0) but desires portability
to native Windows, would I want that *every* malloc call on *all*
non-glibc platforms goes through hoops before it reaches the malloc()
function in libc?

Bruno


Reply via email to