Re: PATCH: zasprintf

[Clint Adams <schizo@xxxxxxxxxx>]

> 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
decently portable.

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
efficient.

> 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?

No idea.

Index: Src/init.c
===================================================================
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 @@
 	return;
     }
 #endif
-    zasprintf(&buf, "%s/%s", h, s);
+    buf = tricat(h, "/", s);
     source(buf);
     zsfree(buf);
 }