On Tue, 30 Nov 2010 13:08:36 +0100, Mikhail Gusarov <[email protected]> wrote: > > Twas brillig at 20:57:37 29.11.2010 UTC-08 when [email protected] > did gyre and gimble: > > AC> The meat of this series is sandwiched right in the middle - patch > AC> #6 replaces the nifty, but unique, Xprintf() API with a local > AC> implementation of the asprintf() family that's becoming widely > AC> adopted (found in recent versions of the GNU, FreeBSD, NetBSD, > AC> OpenBSD, & Solaris libc's, but not yet in all the versions & > AC> platforms we still support). > > Is there particular reason why local implementation of > asprintf/vasprintf have to have X prefix? Why not define them as plain > asprintf/vasprintf from the beginning? (XNF has to stay, sigh).
I think the concern in the past was that we'd accidentally define replacement functions on platforms that already had them, and that these definitions would collide with the system definitions. The usual mechanism in the autoconf world seems to be that you provide a replacement which matches the standard requirements for the function and use the regular name, rather than using a new name. This seems like it would allow people to use existing documentation and not have to re-learn function names. I'd be interested to hear other opinions on whether we should use X-specific functions to avoid any possible collision with the operating system, or if we should trust the autoconf mechanisms to correctly identify systems that do not have a function and then provide a portable standards-compliant implementation using the standard name. -- [email protected]
pgpMIbGDGuNtC.pgp
Description: PGP signature
_______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
