Re: [bug-gnulib] Re: extend the scope of xasprintf

[Bruno Haible]

Eric Blake wrote:
> > +   p = result;
> > +   va_copy (ap, args);
>
> Why are you using va_copy a second time?  vsprintf is allowed to consume
> its va_list argument (aka use va_arg on it), so long as it leaves the
> va_close for the caller.

Right. This is an optim I had neglected. Thanks.

> > +   for (i = argcount; i > 0; i--)
> > +     {
> > +       const char *next = va_arg (ap, const char *);
> > +       size_t len = strlen (next);
> > +       memcpy (p, next, len);
> > +       p += len;
>
> This has now traversed each string three times (two strlen, one memcpy). 
> Would something like strpcpy be more efficient, to cut out one of the
> traversals by looking for string end while copying?

You mean, stpcpy? It's a GNU extension, which means an additional module
dependency. Furthermore I'm not sure stpcpy is faster than strlen + memcpy,
because strlen and memcpy are optimized for operating 4 or 8 bytes at a time,
while strpcpy is not.

> Also, should we worry about a multithreaded environment, if another thread
> changes the string length between when you malloc'd the buffer and copy the
> contents into the buffer?

Reasonable multithreaded programming implies that most objects (parts of memory)
are accessed by a single thread only, and only few objects are accessed from
multiple threads - under control of locks or similar synchronization primitives.
A string has no built-in locking mechanism, therefore it must not be accessed
by multiple threads concurrently.

> Is it worth recognizing the special case of a format string with no "%"
> formatting directives, and do the equivalent of strdup(format) in that
> case?

Are you willing to migrate
       xstrdup (s)    -->    xasprintf ("%s", s)    ?

I wouldn't.

Thanks for the comments!

Bruno