[Gllug] continuing the autoconf saga... AC_FUNC_MALLOC

[Stig Brautaset]

* Nix <nix at esperi.demon.co.uk> spake thus:
> 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.

Should I use `configure.ac' instead of `configure.in'? "info autoconf"
just says to use one or the other, AFAICS it does not say why. Is `.ac'
the new preference?

> >> 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?

Eh... yalll :) 

I wrote `yet another linked-list library' as an exercise, but it turned
up to be so bug-ridden that I scratched it and started over again.
(There's probably a myriad of linked-list libraries around, but I wanted
to code my own for the experience. Also, it is a suitable project to
teach me a bit about how libtool works in conjunction with
autoconf/automake.)

> 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.

I cannot reproduce the bug I witnessed with the new incarnation of my
library (yalla -- yet another linked-list api ;), so I expect it was me
just screwing up royally. *Again*.

> > 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).

Okay, thanks for this.

Since I only need a malloc that will behave correctly with malloc(n),
where n > 0, would it be bad of me to axe this test altogether? Surely
*an* incarnation of malloc will be present on any system that defines
STDC_HEADERS? :)

Stig
-- 
brautaset.org


-- 
Gllug mailing list  -  Gllug at linux.co.uk
http://list.ftech.net/mailman/listinfo/gllug