[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: new module 'calloc-posix'
From: |
Bruno Haible |
Subject: |
Re: new module 'calloc-posix' |
Date: |
Tue, 4 Sep 2007 01:14:13 +0200 |
User-agent: |
KMail/1.5.4 |
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