Re: new module 'calloc-posix'

[Bruno Haible]

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