Re: RFC: AC_DEFINE_REPLACE

[Paul Eggert]

> From: Akim Demaille <address@hidden>
> Date: 26 Mar 2002 11:18:23 +0100
> 
> So I propose that we settle rpl_ as _the_ prefix, or may autoconf_rpl,

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.

For languages like C++ that have better namespace control, presumably
we could do something cleaner.

> Or actually, maybe AC_REPLACE_FUNC should handle this AC_DEFINE
> itself, and would remain the only visible user interface.

I'd prefer that if possible.

> What would change is that now Autoconf would know what are the #define
> corresponding to the replacement of the functions.  _Then_ it will be
> easy to find a scheme to disable the disabling of these functions
> inside configure.

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

  #define func(arg) autoconf_rpl_func (arg)

because it can mishandle system include files that declare or use the
identifier 'func' without giving it arguments.  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'?  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.