From owner-freebsd-arch Thu Jan 11 1: 9:25 2001 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id F3EC537B401 for ; Thu, 11 Jan 2001 01:09:05 -0800 (PST) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id KAA03696; Thu, 11 Jan 2001 10:08:57 +0100 (CET) (envelope-from des@ofug.org) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: "Justin T. Gibbs" Cc: freebsd-arch@FreeBSD.ORG Subject: Re: Proposed chage to sbuf semantics. References: <200101110436.f0B4a5T00319@caspian.scsiguy.com> From: Dag-Erling Smorgrav Date: 11 Jan 2001 10:08:56 +0100 In-Reply-To: "Justin T. Gibbs"'s message of "Wed, 10 Jan 2001 21:36:05 -0700" Message-ID: Lines: 35 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Justin T. Gibbs" writes: > 1) Allow the user to finalize an overflowed buffer. If the user > really cares about overflow, all they need to do is look at > the error code of all previos operations or explicitly check > for overflow prior to finalizing. If the user really wants to finalize an overflowed sbuf, they can explicitly un-overflow it using setpos() (this is documented in the NOTES section of the man page). Please to not change the behavior of sbuf_finish(). > 2) Remove SBUF_HASOVERFLOWED test in sbuf_data(). It can never > be true if we've finalized the sbuf which is an asserted state > for this method. Correct. > 3) Add an SBUF_HASDATA macro that indicates if any data is currently > in the sbuf. sbuf_len() is only available once you finalize an > sbuf or I would have used that. If this is meant to be part of the API, it should be a function (or a macro named and written to look like a function). > 4) Add an SBUF_CLEARFLAG macro to mirror SBUF_SETFLAG(). It is > debatable whether this should be in the exported sbuf API, > but the same could be said for SBUF_SETFLAG(). None of these macros are part of the API. I guess I could have put them in subr_sbuf.c instead of sbuf.c, but I wanted to keep them close to the struct definition. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message