Zsh Mailing List Archive
Messages sorted by:
Re: PATCH: zasprintf
- X-seq: zsh-workers 12818
- From: Clint Adams <schizo@xxxxxxxxxx>
- To: Bart Schaefer <schaefer@xxxxxxxxxxxxxxxxxxxxxxx>
- Subject: Re: PATCH: zasprintf
- Date: Sun, 17 Sep 2000 00:25:52 -0400
- Cc: zsh-workers@xxxxxxxxxxxxxx
- In-reply-to: <1000917004721.ZM18698@xxxxxxxxxxxxxxxxxxxxxxx>; from schaefer@xxxxxxxxxxxxxxxxxxxxxxx on Sun, Sep 17, 2000 at 12:47:20AM +0000
- Mailing-list: contact zsh-workers-help@xxxxxxxxxxxxxx; run by ezmlm
- References: <20000916145333.A29559@xxxxxxxx> <1000917004721.ZM18698@xxxxxxxxxxxxxxxxxxxxxxx>
> 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.
I don't think it's impossible to provide a non-broken implementation;
I just haven't succeeded in doing so in all possible eventualities.
One merely has to solve the annoying gcc prototype problem; deal with
platforms that have no asprintf(), no stdarg, and no varargs, of which
I am unfamiliar; provide a compatibility function for vsnprintf();
and realloc in the event of the limit being reached; and it should be
However, I agree that working everywhere is better than working most
places, so below is a patch to replace the call to zasprintf.
It should now be non-broken and still an improvement.
> 1) Feeping or issuing an error message when a string that might be a
> 2) Copying a string known to be a path name into a temp buffer assumed
Agreed on both cases.
> 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
> 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.
tricat() looks suitable to me; is there some reason it isn't?
> 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?
RCS file: /cvsroot/zsh/zsh/Src/init.c,v
retrieving revision 1.12
diff -u -r1.12 init.c
--- Src/init.c 2000/09/16 18:57:45 1.12
+++ Src/init.c 2000/09/17 03:45:35
@@ -1033,7 +1033,7 @@
- zasprintf(&buf, "%s/%s", h, s);
+ buf = tricat(h, "/", s);
Messages sorted by: