[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