From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10719 invoked from network); 17 Sep 2000 00:48:29 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 17 Sep 2000 00:48:29 -0000 Received: (qmail 2114 invoked by alias); 17 Sep 2000 00:47:45 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 12815 Received: (qmail 2105 invoked from network); 17 Sep 2000 00:47:44 -0000 From: "Bart Schaefer" Message-Id: <1000917004721.ZM18698@candle.brasslantern.com> Date: Sun, 17 Sep 2000 00:47:20 +0000 In-Reply-To: <20000916145333.A29559@dman.com> Comments: In reply to Clint Adams "PATCH: zasprintf" (Sep 16, 2:53pm) References: <20000916145333.A29559@dman.com> X-Mailer: Z-Mail (5.0.0 30July97) To: zsh-workers@sunsite.auc.dk Subject: Re: PATCH: zasprintf MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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 special case): 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() would suffice. 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 http://www.well.com/user/barts http://www.brasslantern.com Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net