Paul Eggert wrote: > To some extent this means "realloc-posix" is trickily named. Yes, glibc > realloc does not conform to POSIX so realloc-posix is within its rights > to replace glibc realloc; but realloc-posix goes beyond what POSIX > requires, and it'll even replace AIX-sans-_LINUX_SOURCE_COMPAT realloc, > which does conform to POSIX. On the other hand we were already > stretching the point here since POSIX allows realloc to succeed with > sizes greater than PTRDIFF_MAX whereas realloc-posix already prohibited > that. Plus, realloc-posix now supplies simple and commonly-assumed > semantics for realloc, so there's that. > > Maybe we should rename realloc-posix back to realloc?
Such a renaming would imply that the module's purpose is to fill in a _missing_ 'realloc' function. If names such as 'realloc-good', 'realloc-decent', etc. are too subjective, then 'realloc-posix' is the best name we have — despite the slight stretch. > The modules amemxfrm, safestriconveh, string-buffer could be simplified > slightly by depending on realloc-posix and assuming the new > realloc-posix behavior. I would say, it's not worth the dependency: a module dependency sometimes adds complexity to the build infrastructure (see e.g. libintl for what I mean), whereas an 'errno = ENOMEM;' assignment in a cold code branch is practically zero-cost. Bruno
