Zsh Mailing List Archive
Messages sorted by:
Re: PATCH: zasprintf
- X-seq: zsh-workers 12815
- From: "Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxxxxxxxxx>
- To: zsh-workers@xxxxxxxxxxxxxx
- Subject: Re: PATCH: zasprintf
- Date: Sun, 17 Sep 2000 00:47:20 +0000
- In-reply-to: <20000916145333.A29559@xxxxxxxx>
- Mailing-list: contact zsh-workers-help@xxxxxxxxxxxxxx; run by ezmlm
- References: <20000916145333.A29559@xxxxxxxx>
On Sep 16, 2:53pm, Clint Adams wrote:
} Subject: PATCH: zasprintf
} In continuation of the crusade against PATH_MAX, this implements
} zasprintf. It will break on systems where there is a stdarg or
} varargs implementation but neither asprintf nor vsnprintf.
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 --
then you should try harder to restrict the problem domain to something
for which you CAN provide a working implementation.
In particular, zsh appears to use PATH_MAX in four cases (plus one
1) Feeping or issuing an error message when a string that might be a
path name is "too long," even though that string isn't immediately
going to be copied into a buffer or even used as a pathname. In
most of these cases I think we could just drop the test entirely.
2) Copying a string known to be a path name into a temp buffer assumed
to be large enough to hold it. A call to dupstring() or ztrdup()
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).
4) Pasting together two partial path names to make one longer path.
This is the case where the patch in 12814 uses zasprintf() -- but
it's overkill, it'd be sufficient to call strlen() on each of the
two parts to preallocate a large enough buffer. A simple function
similar to dyncat() or tricat() would work.
None of those require varargs, stdarg, snprintf, etc.
The last, special case is to create a "big enough" buffer for use by
readlink(). In this case I think we could use lstat() to read the size
of the link itself, and use that to allocate a buffer. Does anyone
know of an operating system where that would fail?
Bart Schaefer Brass Lantern Enterprises
Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net
Messages sorted by: