Re: PATCH: zasprintf

["Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxxxxxxxxx>]

On Sep 17, 12:25am, Clint Adams wrote:
} Subject: Re: PATCH: zasprintf
}
} > This seems to me to be the wrong way to approach this issue.  If you
} > can't provide a non-broken implementation -- and I don't see how you
} > can, if you don't plan to implement a printf-format-string parser --
} 
} I don't think it's impossible to provide a non-broken implementation;

I don't think it's impossible either, but the only way to "provide a
compatibility function for vsnprintf()" is to implement a parser for
printf format-strings.  There simply is no way to fake it if you don't
have it.  I don't believe there's any use zsh could make of asprintf()
that isn't better solved another way.  In particular:

} > 3) Pasting a string obtained from readdir() onto a known path prefix.
} >    In this case, it would be sufficient to use NAME_MAX + strlen()
} >    (and use pathconf() to get NAME_MAX if necessary).
} 
} I'm uncomfortable with this after the other pathconf episode, especially
} since pathconf() might return -1 for NAME_MAX, and then we've got
} to deal with that by either arbitrarily setting a value or by dynamically
} resizing, whereas I presume asprintf() would be cleaner and more
} efficient.

I don't have any such confidence that asprintf() would be cleaner or more
efficient than, say, a realloc'ing version of tricat() that takes a char**
to an allocated string as its first parameter.

As for pathconf() ... as far as I can tell NAME_MAX has none of the odd
problems associated with PATH_MAX.  It doesn't, for example, potentially
vary from call to call within the same directory.  The only tricky bit
is dealing with -1, which brings us back to the realloc'ing tricat().

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net