Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 11 Jan 2001 07:34:40 -0700
From:      "Justin T. Gibbs" <gibbs@scsiguy.com>
To:        Dag-Erling Smorgrav <des@ofug.org>
Cc:        freebsd-arch@FreeBSD.ORG
Subject:   Re: Proposed chage to sbuf semantics. 
Message-ID:  <200101111434.f0BEYes28373@aslan.scsiguy.com>
In-Reply-To: Your message of "11 Jan 2001 10:08:56 %2B0100." <xzpk882317b.fsf@flood.ping.uio.no> 

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().

This means the caller must know the length of the buffer and set
the position correctly.  If the sbuf is passed into a routine,
this requires looking inside the sbuf to determine the buffer
size.  It was my understanding that sbufs should be treated
as opaque.  I'd rather have the code to fix an overflow written
once an available in the sbuf code than force each client to
get this right.

>> 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).

Why is this different than any of the other macro predicates?  Or
are the predicates not part of the interface.  If so, they should
be moved to the .c file.

>> 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.

I didn't read the man page, I read the code.  Having these macros
in the header invites their usage.

--
Justin


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?200101111434.f0BEYes28373>