Date: Tue, 17 Jan 2012 12:22:26 -0700 From: Scott Long <scottl@samsco.org> To: John Baldwin <jhb@FreeBSD.org> Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, Eitan Adler <eadler@FreeBSD.org>, Colin Percival <cperciva@FreeBSD.org> Subject: Re: svn commit: r230125 - head/sys/kern Message-ID: <CF79A730-86D4-4A73-BDFF-C3F1B93EA330@samsco.org> In-Reply-To: <201201171008.28752.jhb@freebsd.org> References: <201201150709.q0F79Iif067938@svn.freebsd.org> <4F136109.9050004@FreeBSD.org> <4F13621B.1060203@freebsd.org> <201201171008.28752.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jan 17, 2012, at 8:08 AM, John Baldwin wrote: > On Sunday, January 15, 2012 6:32:43 pm Colin Percival wrote: >> On 01/15/12 15:28, John Baldwin wrote: >>> On 1/15/12 2:09 AM, Eitan Adler wrote: >>>> Log: >>>> - Fix undefined behavior when device_get_name is null >>>> - Make error message more informative >>> >>> The in-kernel printf(9) always prints "(null)" for %s when the pointer is NULL, >>> so that wasn't undefined behavior. Printing out the driver name is a useful >>> change, but the "(unknown)" bits are just noise as it isn't clear that >>> "(unknown)" is substantially better than "(null)". >> >> I think the change from "(null)" to "(unknown)" is useful, since when I see >> "(null)" printed my immediate thought is "looks like there's a bug I need to >> track down here". > > The entire printf is "there's a bug I need to track down here". (null) > explicitly tells me that device_get_name() is NULL when looking at the printf > to see what it means. Having it be (unknown) tells me the same exact thing, > but only after I've parsed an extra 2-3 lines of code to figure out what > (unknown) stands for. > I like that change. "null" is ambiguous for those who aren't intimately familiar with the bus code. Scott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CF79A730-86D4-4A73-BDFF-C3F1B93EA330>