Date: Sat, 10 Dec 2011 15:20:09 GMT From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> To: freebsd-bugs@FreeBSD.org Subject: Re: kern/163076: It is not possible to read in chunks from linprocfs and procfs. Message-ID: <201112101520.pBAFK9FT035322@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/163076; it has been noted by GNATS.
From: "Poul-Henning Kamp" <phk@phk.freebsd.dk>
To: Jaakko Heinonen <jh@FreeBSD.org>
Cc: Petr Salinger <Petr.Salinger@seznam.cz>, bug-followup@FreeBSD.org,
des@FreeBSD.org, mdf@FreeBSD.org
Subject: Re: kern/163076: It is not possible to read in chunks from linprocfs and procfs.
Date: Sat, 10 Dec 2011 15:15:56 +0000
In message <20111207160834.GA2257@a91-153-116-96.elisa-laajakaista.fi>, Jaakko
Heinonen writes:
>Could we just remove the error check from sbuf_len()? (patch below) I
>have Cc'd more people.
>
>sbuf(9) manual page wrongly claims that sbuf_data() will return NULL if
>the buffer has overflowed.
Let me just back up to the beginning to make sure we're not headed
into the weeds here:
The idea behind sbufs is to have text-composition with a latching
error handling, so that error checks only needs to be done once,
and not after each and every *printf() &c. call.
I agree with Dag-Erling that it is at least mistake to not have
separate sbuf(9) and sbuf(3) pages, possibly also a mistake that
they share the implementation.
I cannot say that I very much like the "drain" stuff that was added,
That just sticks out like a sore thumb and the way the drain function
clutters up the explanation in the manual-page indicates that it
is a mis-fit bolt on.
Obviously sbuf_finish() should return the error status, and its
return value SHALL be checked by applications, before the contents
of the sbuf can be used.
The argument relating to this bug is about what sbuf_len() and
sbuf_data() should return for an error'ed sbuf.
Given that the mandatory error-check of the sbuf_finish() call
should prevent these two functions from being called in the first
place, I'm tempted to say that their return values should be
documented as undefined, and implemented to cause the maxium amount
of havoc (ie: -1 and NULL).
It can be argued, that sbuf_len(), like snprintf(3) should return
how long the result would have been, had there been enough space
and no trouble.
This argument has merit but I'm not going to entertain it, until a
credible usecase has been shown, because the main reason snprintf(3)
does that, is to make it possible to implement what sbufs provide
a more convenient API for.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201112101520.pBAFK9FT035322>