From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [Qemu-devel] KVM call minutes for Feb 15 Date: Thu, 17 Feb 2011 11:26:03 +0200 Message-ID: <4D5CE9AB.2030503@redhat.com> References: <20110215162629.GN21720@x200.localdomain> <4D5B0889.4030303@codemonkey.ws> <4D5BA5E9.90307@redhat.com> <4D5BD259.3080804@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Chris Wright , qemu-devel@nongnu.org, kvm@vger.kernel.org To: Anthony Liguori Return-path: Received: from mx1.redhat.com ([209.132.183.28]:54182 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754041Ab1BQJ4T (ORCPT ); Thu, 17 Feb 2011 04:56:19 -0500 In-Reply-To: <4D5BD259.3080804@codemonkey.ws> Sender: kvm-owner@vger.kernel.org List-ID: On 02/16/2011 03:34 PM, Anthony Liguori wrote: > On 02/16/2011 04:24 AM, Avi Kivity wrote: >> On 02/16/2011 01:13 AM, Anthony Liguori wrote: >>> On 02/15/2011 10:26 AM, Chris Wright wrote: >>>> QAPI and QMP >>>> - Anthony adding a new wiki page to describe all of this >>> >>> http://wiki.qemu.org/Features/QAPI >>> >> >> [ 'change', {'device': 'str', 'target': 'str'}, {'arg': 'str'}, >> 'none' ] >> -> >> void qmp_change(const char *device, const char *target, bool >> has_arg, const char *arg, Error **errp); >> >> AFAICT a json-string allows embedded NULs ('\0000'). There translate >> to UTF-8 as '\0', terminating your char *s. Either we use some >> length/pointer structure, or the parser has to look for them and kill >> them, and we have to specify them as verboten. > > I feel like it would be safer for us to not accept strings with > embedded NULs. There's no way we're going to consistently handle this > correctly in QEMU since we expect NUL terminated strings. They won't > work for any of the standard C functions either. I agree. Technically we're making a backwards incompatible change to the protocol specification, but I don't think there's any risk that somebody is sending in strings with NULs. (btw what happens in a non-UTF-8 locale? I guess we should just reject unencodable strings). -- error compiling committee.c: too many arguments to function