Date: Fri, 13 Mar 2015 13:19 -0400 From: John Baldwin <jhb@freebsd.org> To: Ian Lepore <ian@freebsd.org> Cc: "svn-src-head@freebsd.org" <svn-src-head@freebsd.org>, "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>, "src-committers@freebsd.org" <src-committers@freebsd.org>, Ryan Stone <rysto32@gmail.com> Subject: Re: svn commit: r279932 - head/sys/vm Message-ID: <3013452.2FfDYxpIKo@ralph.baldwin.cx> In-Reply-To: <1426263267.91779.19.camel@freebsd.org> References: <201503121806.t2CI6VSU034853@svn.freebsd.org> <29142844.yUiOLJLpmU@ralph.baldwin.cx> <1426263267.91779.19.camel@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Friday, March 13, 2015 10:14:27 AM Ian Lepore wrote: > On Fri, 2015-03-13 at 06:24 -0400, John Baldwin wrote: > > On Thursday, March 12, 2015 05:24:51 PM Ian Lepore wrote: > > > On Thu, 2015-03-12 at 17:02 -0400, Ryan Stone wrote: > > > > On Thu, Mar 12, 2015 at 2:06 PM, Ian Lepore <ian@freebsd.org> wrote: > > > > > > > > > Nullterminate strings returned via sysctl. > > > > > > > > > > PR: 195668 > > > > > > > > > > > > > To quote the manpage: > > > > > > > > > The *sbuf* family of functions allows one to safely > > > > > allocate, construct and release bounded null-terminated > > > > > strings in kernel space. > > > > > > > > IMO the sbuf API is broken if we have to explicitly null-terminate the > > > > string ourselves. > > > > > > If we want the nullterm to be counted in the length of data in the > > > buffer (and thus get transmitted back across the syscall boundary) we > > > need to put an explicit counted nullterm byte into the buffer. > > > > > > I had started down the path of making that (counting the nullterm byte > > > as part of the data in the buffer) a feature of sbuf that you could set > > > with a flag, but then whoever added sbuf_new_for_sysctl() didn't > > > propagate the flags field through the new function and I decided to not > > > go off into the weeds making a new flavor of that takes flags. > > > > One suggestion would be to consider using '\0' for a nul character instead of > > a bare 0. To me that communicates the intention more clearly to the reader. > > (One of the things I did not like about C++ < C++11 was the use of 0 for > > NULL. I much prefer nullptr and NULL in C over bare 0's for pointers for > > similar clarity reasons.) > > > > I have waffled back and forth between preferring 0 or '\0' for 30 years, > I just seem to go through phases with nullterm expression. > > In general I'm glad I got called away to an onsite meeting yesterday and > didn't get far with these changes, because the more I think about it, > the less satisfied I am with this expedient fix. The other fix I > started on, where a new SBUF_COUNTNUL flag can be set to inform the > sbuf_finish() code that you want the terminating nul counted in the data > length just feels like a better fit for the overall "automaticness" of > how the sbuf stuff works. Hmm, I actually think that it's a bug that the terminating nul isn't included when draining. If we fixed that then I think that fixes most of these? The places that explicitly use 'sysctl_handle_string()' with an sbuf should probably just be using sbuf_len(sb) + 1' explicitly. (Another option would be to have a sysctl_handle_sbuf() that was a wrapper around sysctl_handle_string() that included the + 1 to hide that detail if there is more than one.) -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3013452.2FfDYxpIKo>