Re: RFC: AC_DEFINE_REPLACE

[Russ Allbery]

Paul Eggert <address@hidden> writes:

> I think rpl_ would be OK.  I just checked a lot of free software, and
> the only uses of a rpl_ prefix were for this particular purpose.

> However, it would be cleaner to use a prefix reserved to Autoconf, and
> also it might aid the transition from the hand-built replacement code
> to the Autoconf-supplied replacements.  Since programmers normally
> don't see the longer names, I think 'autoconf_rpl_' would be OK.  I
> don't think we need to worry about linkers that insist on tiny names
> any more.

I realize that it's not technically allowed by the C standard, but are
there platforms where interposition actually doesn't work?

When I want to replace a C library function that's broken, I just link in
a file that provides that function.  It's always worked for me.  That way,
one doesn't have to worry about odd prefixes or the excessive effects of
#define (for example, #define malloc rpl_malloc also affects struct
malloc, which is almost never what you really want).

> One problem comes to mind, though.  We can't put this into config.h:

>   #define func(arg) autoconf_rpl_func (arg)

In more ways than one; consider variadic functions.  Variadic macros
aren't even remotely portable yet.

> So, I guess you want to do put this into config.h instead:

>   #define func autoconf_rpl_func

> But won't this run into problems if a system include file also has
> '#define func'?

So will the above, won't it?  You don't get away from that problem just by
defining the macro to take arguments, as I understand it.

> For example, Solaris 8 <sys/stat.h> has this in some cases:

> #define       stat    stat64

> and this would collide with autoconf's definition, if it tried to
> replace 'stat'.

> As it happens, none of the functions replaced by, say, textutils has
> this problem on Solaris.  But I think it's simply a matter of time
> before we run into the problem.

Yup.  If you have to replace any function that has an alternate 64-bit
entry point, you run into this problem.

-- 
Russ Allbery (address@hidden)             <http://www.eyrie.org/~eagle/>