From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11944 invoked from network); 17 Sep 2000 04:26:31 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 17 Sep 2000 04:26:31 -0000 Received: (qmail 14358 invoked by alias); 17 Sep 2000 04:25:57 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 12818 Received: (qmail 14350 invoked from network); 17 Sep 2000 04:25:55 -0000 Date: Sun, 17 Sep 2000 00:25:52 -0400 From: Clint Adams To: Bart Schaefer Cc: zsh-workers@sunsite.auc.dk Subject: Re: PATCH: zasprintf Message-ID: <20000917002552.A31354@dman.com> References: <20000916145333.A29559@dman.com> <1000917004721.ZM18698@candle.brasslantern.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.1.2i In-Reply-To: <1000917004721.ZM18698@candle.brasslantern.com>; from schaefer@candle.brasslantern.com on Sun, Sep 17, 2000 at 12:47:20AM +0000 > 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); }