Re: realloc.c on Tru64 4.0D

[Ralf Wildenhues]

Hello Bruno,

Sorry for the delay.

* Bruno Haible wrote on Tue, Oct 23, 2007 at 01:08:54AM CEST:
> Ralf Wildenhues wrote:
> > on Tru64 4.0D I got this:
> > 
> > | cc -DHAVE_CONFIG_H -DEXEEXT=\"\" -DEXEEXT=\"\" -DNO_XMALLOC -DEXEEXT=\"\" 
> > -I. -I.. -I../../dummy-0/gllib  -I../intl -ieee  -g -c -o realloc.o 
> > ../../dummy-0/gllib/realloc.c
> > | cc: Error: ../../dummy-0/gllib/realloc.c, line 56: In this statement, a 
> > common type could not be determined for the 2nd and 3rd operands 
> > ("malloc(...)" and "realloc(...)") of a conditional operator. (badcondit)
> > |   result = (p == NULL ? malloc (n) : realloc (p, n));
> > | ------------^
> > | gmake[3]: *** [realloc.o] Error 1
> > 
> > ... due to malloc being #defined
> > but not restored like realloc in realloc.c, there is a type mismatch,
> > as the rpl_malloc function is not declared.
> 
> Thanks for the analysis. Your patch does two things:
> 
> - You realized that when REALLOC_0_IS_NONNULL && ! MALLOC_0_IS_NONNULL
>   the code is wrong because it may malloc(0).

Yes.

>   A good point. Can you prepare
>   a fix for this that is independent from the other issue?

I may be able to once I understand the following:

> - It does weird #undef games to get the malloc() declaration from the system.
>   The problem is that malloc is already defined to rpl_malloc in config.h.
>   This idiom comes from the times when we did the function replacements in
>   config.h.

Well, it comes from the age-old interface of AC_FUNC_MALLOC (upon which
lots of non-gnulib code relies, BTW).

Are you suggesting that gnulib not use AC_FUNC_MALLOC, but use a copy of
its own that does not #define malloc to rpl_malloc?  Isn't that
unnecessary code duplication?  Sorry, I just fail to see what's weird
about it; esp. since it also requires gnulib users to not use
AC_FUNC_MALLOC, which the current scheme is robust against.

>   Now we normally do them in the appropriate header file substitute,
>   such as in stdlib.h. This has the advantage that we can first include the
>   original <stdlib.h>, to get malloc()'s original function declaration, and
>   then only we '#define malloc rpl_malloc' and provide a function declaration
>   for rpl_malloc.

Well, but the way the malloc module works now, it, well, works.  What's
better about the other way?

>   The 'malloc-posix' module already uses this new idiom. Can you change the
>   'malloc' module to use the new idiom as well? This will fix this issue.

Thanks for enlightening me.

Cheers,
Ralf