Hi Eric, > I guess the module rename would make it obvious to anyone using the old > 'malloc' module that they now need to choose which semantics they want, > the simpler 'malloc-gnu' or the POSIX-compliant 'malloc-posix'.
Yes. > On the > other hand, 'malloc-gnu' sort of implies the errno-setting behavior, since > glibc obeys POSIX in this regard Yes, malloc-gnu will have a dependency on malloc-posix. > in which case I don't see a need to > distinguish, and we might as well go with the simpler module 'malloc' that > does it all for everyone. Ah no, these are very different things: malloc-posix penalizes only mingw. Whereas malloc-gnu causes a wrapper to be used on Solaris, on FreeBSD, etc. - on all systems except glibc. I don't want to use malloc-gnu in my programs, since the malloc in Solaris, FreeBSD etc. is perfectly fine, and I'm careful enough not to make useless allocation calls like malloc(0). It takes a little more code proofreading time to guarantee this than to blindly assume malloc-gnu, but I do this. - Other people's mileage varies, of course. > For fnmatch-gnu, I can see where there are > extensions beyond POSIX, but not in your proposed malloc-gnu. The extension beyond POSIX in malloc-gnu is the treatment of malloc(0). glibc guarantees you that malloc(0) will waste a block of memory, whereas in POSIX you can normally also have malloc(0) => NULL. > It may be worth considering using AC_COMPILE_IFELSE rather than the > obsolete AC_TRY_COMPILE, now that gnulib requires autoconf 2.59 or better. We have dozens of AC_TRY_COMPILE already. Why not one more? With AC_COMPILE_IFELSE, one is tempted to make mistakes like this: - forgetting about AC_LANG_PROGRAM, - making quoting mistakes in the arguments of AC_LANG_PROGRAM. Bruno
