[Gllug] continuing the autoconf saga... AC_FUNC_MALLOC
Nix
nix at esperi.demon.co.uk
Sun Jun 30 10:08:22 UTC 2002
On Sat, 29 Jun 2002, Stig Brautaset said:
> Although sometimes it claims to be 2.13 (debian will not let me install
> 2.5X without installing 2.13 as well). I imagine it is due to some
> "clever" wrapper that tries to figure out what you need or something.
Yes, it is. Call `autoconf-2.53' directly if you want to force it,
although if your configure.ac is called, um, configure.ac, or you have a
suitable AC_PREREQ, it should determine the right autoconf version for
you.
(If it doesn't, it's a bug.)
>> It works for me with autoconf-2.53, given a configure.ac like this:
>> AC_INIT(foo,0.01)
>> AC_CONFIG_HEADERS(config.h)
>> AC_PROG_CC
>> AC_PROG_CC_STDC
>> AC_FUNC_MALLOC
>> AC_OUTPUT
>
> This works for me too. But, it wouldn't work with my configure.in --
> after a bit of trial and error it turns out the AC_FUNC_MALLOC macro
> does not like to be used after the AC_CHECK_LIB macro..
*boggle* What are you AC_CHECK_LIBbing?
> Although it is explicitly stated in the autobook that putting tests for
> functions should come after tests for libraries etc..
True (since otherwise you might try to use a function without having
checked to see if the library it's in even exists yet).
> Maybe it is a special case for this macro since one can load a library
> to use your own malloc if it is not working?
Nope, it sounds more like a bug.
It would be much easier for me to replicate it if I could see your
configure.ac though :) or preferably a minimal subset that causes this
behaviour.
> PS: On a related note, is there any reason why you would ever want
> to do a malloc(0)?
No, but you might want to do a malloc(n) for a range of n that includes
zero, and your algorithm might depend upon all the n's being distinct
(for pointer comparisons, say).
Fairly grotty, but I've seen it (in graph comparison code in a natural
language program). It can simplify a good bit of code, but unfortunately
because it's not guaranteed behaviour, you promptly have to add all that
complexity back again to work on systems where the guarantee doesn't
hold ;)
--
`What happened?'
`Nick shipped buggy code!'
`Oh, no dinner for him...'
--
Gllug mailing list - Gllug at linux.co.uk
http://list.ftech.net/mailman/listinfo/gllug
More information about the GLLUG
mailing list