From owner-freebsd-arch  Mon Feb 26 22:16:39 2001
Delivered-To: freebsd-arch@freebsd.org
Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16])
	by hub.freebsd.org (Postfix) with ESMTP id A08A737B67D
	for <arch@FreeBSD.ORG>; Mon, 26 Feb 2001 22:16:35 -0800 (PST)
	(envelope-from bde@zeta.org.au)
Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102])
	by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id RAA04558;
	Tue, 27 Feb 2001 17:16:29 +1100
Date: Tue, 27 Feb 2001 17:16:27 +1100 (EST)
From: Bruce Evans <bde@zeta.org.au>
X-Sender: bde@besplex.bde.org
To: "Kenneth D. Merry" <ken@kdm.org>
Cc: arch@FreeBSD.ORG
Subject: Re: sbufs in userland
In-Reply-To: <20010226160907.A26335@panzer.kdm.org>
Message-ID: <Pine.BSF.4.21.0102271701190.23480-100000@besplex.bde.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-arch@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Mon, 26 Feb 2001, Kenneth D. Merry wrote:

> On Tue, Feb 27, 2001 at 04:05:34 +1100, Bruce Evans wrote:
> > This seems to be insufficiently large to be correct :-).  It doesn't check
> > for snprintf failing (retlen == -1) or truncating (retlen >= tmpstrlen).
> 
> True, something like this might do the trick:
> 
> 	switch (error_code) {
> 	case SSD_DEFERRED_ERROR:
> 		retlen = snprintf(tmpstr, tmpstrlen, "Deferred Error: ");
> 
> 		if (((tmplen = str_len - cur_len - 1) < 0) || (retlen == -1))
> 			goto sst_bailout;
> 
> 		strncat(str, tmpstr, tmplen);
> 		cur_len += min(retlen, tmpstrlen);
> 		str[str_len - 1] = '\0';
> 		/* FALLTHROUGH */
> 
> I think failures are unlikely -- tmpstr is generally long enough to handle
> anything thrown at it, and I think most of the cases that would cause
> snprintf() to return -1 are unlikely with our code.  The most likely
> scenario that would cause it would be some sort of integer conversion
> overflow.

I think snprintf() is very unlikely to return -1 (integer conversion overflow
gives undefined behaviour and isn't checked for in our implementation, so it
won't cause snprintf() to return -1 ...).

The check for retlen < tmpstrlen (indirectly via min()) has a off-by-1
error.

> > funopen() is more general than sbufs, so it is not quite as easy to use,
> > but I think it is easy enough.
> 
> As Poul-Henning pointed out, it would need to be available in the kernel as
> well as userland in order to accomplish the goal of getting rid of
> functionally duplicated code.

So everyone agrees that sbufs are a mistake :-).  The kernel should use
the same interfaces as userland for general things like printf() and
malloc() (oops, too late), if it needs such interfaces at all, so that
programmers can reuse their knowledge of userland.  However, I doubt
that general string handling in the kernel is needed often enough to
justify having sbuf or funopen.

Bruce


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message