Paul Eggert <[EMAIL PROTECTED]> 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 ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
