Zsh Mailing List Archive
Messages sorted by:
Re: PATCH: zasprintf
- X-seq: zsh-workers 12822
- From: "Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxxxxxxxxx>
- To: Clint Adams <schizo@xxxxxxxxxx>
- Subject: Re: PATCH: zasprintf
- Date: Sun, 17 Sep 2000 16:13:56 +0000
- Cc: zsh-workers@xxxxxxxxxxxxxx
- In-reply-to: <20000917110403.A4270@xxxxxxxx>
- Mailing-list: contact zsh-workers-help@xxxxxxxxxxxxxx; run by ezmlm
- References: <20000916145333.A29559@xxxxxxxx> <1000917004721.ZM18698@xxxxxxxxxxxxxxxxxxxxxxx> <20000917002552.A31354@xxxxxxxx> <1000917053751.ZM18817@xxxxxxxxxxxxxxxxxxxxxxx> <20000917110403.A4270@xxxxxxxx>
On Sep 17, 11:04am, Clint Adams wrote:
} Subject: Re: PATCH: zasprintf
} > I don't believe there's any use zsh could make of asprintf()
} > that isn't better solved another way.
} If by "better" you mean "avoiding asprintf and dealing with a specialized
I do, mostly because I don't think there are very many specialized cases.
There are 96 uses of sprintf() in zsh, nearly all of them used to convert
integers to strings (which hardly requires a dynamically allocated buffer).
Several of the remaining ones are used for path concatenation. None have
particularly complex format strings.
I simply think that asprintf() is over-generalized.
} > I don't have any such confidence that asprintf() would be cleaner or more
} > efficient than, say, a realloc'ing version of tricat()
} Why, other than portability?
For one thing, because it can't realloc(). That means that if you use it
in a loop, you have to allocate and free the buffer every time around,
even if you're always writing approximately the same size string.
For another thing:
} Speaking of the real tricat, this eliminates bin_dot's dependence on
This is a case where a zsh-heap-allocating version of tricat() would be
slightly preferable to a permanent-heap-allocating version.
Bart Schaefer Brass Lantern Enterprises
Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net
Messages sorted by: