[PATCH 00/11] Xasprintf() and other string-handling cleanups

Keith Packard keithp at keithp.com
Tue Nov 30 09:32:04 PST 2010


On Tue, 30 Nov 2010 13:08:36 +0100, Mikhail Gusarov <dottedmag at dottedmag.net> wrote:
> 
> Twas brillig at 20:57:37 29.11.2010 UTC-08 when alan.coopersmith at oracle.com 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.

-- 
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg-devel/attachments/20101130/2d5dff5d/attachment.pgp>


More information about the xorg-devel mailing list