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

[Alan Coopersmith]

Keith Packard wrote:
> 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.

Or build against a libc package without them, then upgrade to a newer libc
without rebuilding the server and drivers.

It does make it clearer in stack traces if it's the libc or Xorg implementation
that a bug is in, but that's easily determinable other ways (nm Xorg | grep
asprintf), and our implementation is still mostly just a wrapper around libc's
other printf routines.

> 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.

I guess we have both styles in the tree now, and I was just following
the examples of the other allocation functions, and not the examples of
os/str*.c.

I can live with either way if we have a consensus on which style to follow
for cases like this going forward.

I suppose the biggest question is if this is a function drivers would want
to use, and if so should Xorg expose it as part of the ABI for them
regardless of underlying libc support?   i.e. if you build a driver against
Xorg that provided asprintf() and then upgrade libc & rebuild Xorg should
asprintf() disappear from the ABI and break drivers?   Xasprintf() is much
easier to maintain in the ABI than portably wrapping a function of the same
name.   (I know how to do it with ELF filters using Solaris linker mapfiles,
and have heard from Adam that GNU ld has ELF filter support, but I don't
know if that covers all platforms we care about - though I suppose we don't
need to worry about Xorg loadable module ABI on OSX or Cygwin.)

-- 
	-Alan Coopersmith-        alan.coopersmith at oracle.com
	 Oracle Solaris Platform Engineering: X Window System