From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18208 invoked from network); 17 Sep 2000 12:21:22 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 17 Sep 2000 12:21:22 -0000 Received: (qmail 27645 invoked by alias); 17 Sep 2000 12:20:46 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 12820 Received: (qmail 27638 invoked from network); 17 Sep 2000 12:20:46 -0000 Subject: Re: PATCH: zasprintf In-Reply-To: <1000917004721.ZM18698@candle.brasslantern.com> from Bart Schaefer at "Sep 17, 2000 00:47:20 am" To: Bart Schaefer Date: Sun, 17 Sep 2000 13:21:23 +0100 (BST) CC: zsh-workers@sunsite.auc.dk X-Mailer: ELM [version 2.4ME+ PL66 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: From: Zefram Bart Schaefer wrote: >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? $ uname -sr Linux 2.2.12-20 $ ls -l /proc/self/cwd lrwx------ 1 zefram zefram 0 Sep 17 13:17 /proc/self/cwd -> /home/zefram $ Some other bits of /proc do this too. And on any system, a link could be replaced between the lstat() and the readlink(). I think it would be reasonable to use lstat() for a first guess, but we have to fall back on an algorithm of increasing the buffer size until it's big enough. -zefram