> From: Akim Demaille <[EMAIL PROTECTED]> > 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.
