Date: 11 Jan 2001 10:08:56 +0100 From: Dag-Erling Smorgrav <des@ofug.org> To: "Justin T. Gibbs" <gibbs@scsiguy.com> Cc: freebsd-arch@FreeBSD.ORG Subject: Re: Proposed chage to sbuf semantics. Message-ID: <xzpk882317b.fsf@flood.ping.uio.no> In-Reply-To: "Justin T. Gibbs"'s message of "Wed, 10 Jan 2001 21:36:05 -0700" References: <200101110436.f0B4a5T00319@caspian.scsiguy.com>
next in thread | previous in thread | raw e-mail | index | archive | help
"Justin T. Gibbs" <gibbs@scsiguy.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?xzpk882317b.fsf>