zsh-workers
 help / color / mirror / code / Atom feed
From: "Bart Schaefer" <schaefer@candle.brasslantern.com>
To: zsh-workers@sunsite.auc.dk
Subject: Re: PATCH: zasprintf
Date: Sun, 17 Sep 2000 00:47:20 +0000	[thread overview]
Message-ID: <1000917004721.ZM18698@candle.brasslantern.com> (raw)
In-Reply-To: <20000916145333.A29559@dman.com>

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   


  reply	other threads:[~2000-09-17  0:48 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-09-16 18:53 Clint Adams
2000-09-17  0:47 ` Bart Schaefer [this message]
2000-09-17  1:10   ` PATH_MAX again Bart Schaefer
2000-09-17  4:25   ` PATCH: zasprintf Clint Adams
2000-09-17  5:37     ` Bart Schaefer
2000-09-17 15:04       ` Clint Adams
2000-09-17 16:13         ` Bart Schaefer
2000-09-17 16:43           ` Clint Adams
2000-09-17 12:21   ` Zefram
2000-09-18 13:28 ` Andrej Borsenkow

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1000917004721.ZM18698@candle.brasslantern.com \
    --to=schaefer@candle.brasslantern.com \
    --cc=zsh-workers@sunsite.auc.dk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).