[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: RFC: AC_DEFINE_REPLACE
From: |
Russ Allbery |
Subject: |
Re: RFC: AC_DEFINE_REPLACE |
Date: |
Tue, 26 Mar 2002 12:06:48 -0800 |
User-agent: |
Gnus/5.090005 (Oort Gnus v0.05) XEmacs/21.4 (Common Lisp, sparc-sun-solaris2.6) |
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/>