kern/163076: It is not possible to read in chunks from linprocfs and procfs.

[Poul-Henning Kamp]

The following reply was made to PR kern/163076; it has been noted by GNATS.

From: "Poul-Henning Kamp" <phk at phk.freebsd.dk>
To: Jaakko Heinonen <jh at FreeBSD.org>
Cc: Petr Salinger <Petr.Salinger at seznam.cz>, bug-followup at FreeBSD.org,
        des at FreeBSD.org, mdf at 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 at 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 at 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.