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