From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41797) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bVYuJ-0000Gd-AG for qemu-devel@nongnu.org; Fri, 05 Aug 2016 02:47:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bVYuD-0001wZ-BR for qemu-devel@nongnu.org; Fri, 05 Aug 2016 02:46:58 -0400 Received: from mx1.redhat.com ([209.132.183.28]:34876) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bVYuD-0001va-3S for qemu-devel@nongnu.org; Fri, 05 Aug 2016 02:46:53 -0400 From: Markus Armbruster References: <57A3A7F0.3000604@redhat.com> Date: Fri, 05 Aug 2016 08:46:49 +0200 In-Reply-To: <57A3A7F0.3000604@redhat.com> (Eric Blake's message of "Thu, 4 Aug 2016 14:39:12 -0600") Message-ID: <87wpjv7lwm.fsf@dusky.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Qemu-devel] qtest protocol: should memset/read/write etc of a size of 0 bytes be permitted? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: Peter Maydell , QEMU Developers , John Snow Eric Blake writes: > On 08/04/2016 12:46 PM, Peter Maydell wrote: >> I've upgraded to a more recent version of clang, which now produces >> undefined-behaviour warnings for passing NULL pointers to some library >> functions. One of the things it has shown up is that some of the >> qtest tests ask for "memset" with size zero. In our current implementation >> this results in qtest.c calling g_malloc(0), which returns NULL, and > > I never understood why glib made that choice on g_malloc(0). I would > much prefer it to ALWAYS return something, just as glibc malloc(0) does. I guess it made the choice because unlike malloc(0), it can't cause confusion. malloc() returning null can mean either error or nothing. The caller should pick nothing when it passed zero. g_malloc() returning null can only mean nothing. >> then calling memset(NULL, chr, 0), which is UB. > > Indeed, although I really wish POSIX could be loosened to say that the > source pointer is untouched if the length is 0 (I've debated about > filing a POSIX bug report to that effect, but have not done so yet), so > that the UB only happens when passing NULL with a non-zero size. For me, this is one of those pointless UBs, whose only effect on the real world is wasting programmer time. Seriously, what else could a sane memset(NULL, 0, 0) do? What could anyone gain from an insane memset() other than the glee of telling people "your program is wrong, and you're !". The mission of this standard is to codify existing practice. Show me a real-world implementation of memset() that does something other than nothing when passed a zero size, and whose maintainers don't consider that a bug in need of fixing. >> So should we: >> (1) declare the qtest protocol commands 'memset', 'read', 'write' >> etc which operate on a lump of guest memory of specified size to >> support size == 0 as meaning "do nothing" > > My preference - even if we have to special case things to avoid UB at > the lower level, presenting well-defined behavior at the upper level is > easier to think about. > >> (2) declare that size == 0 is not valid and make it return a failure >> code back down the qtest pipe (and fix the offending tests) > > Doable, but not as fun to audit, and not my preference. Concur. We shouldn't slavishly replicate an underlying interface's complexities when we can just as well provide a more regular interface instead.