From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:44277) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RceyN-0002cm-U4 for qemu-devel@nongnu.org; Mon, 19 Dec 2011 10:17:57 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RceyI-0006ac-6w for qemu-devel@nongnu.org; Mon, 19 Dec 2011 10:17:51 -0500 Received: from mx1.redhat.com ([209.132.183.28]:2045) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RceyH-0006aY-TR for qemu-devel@nongnu.org; Mon, 19 Dec 2011 10:17:46 -0500 Message-ID: <4EEF5591.2010207@redhat.com> Date: Mon, 19 Dec 2011 17:17:37 +0200 From: Avi Kivity MIME-Version: 1.0 References: <1324304024-11220-1-git-send-email-avi@redhat.com> <1324304024-11220-2-git-send-email-avi@redhat.com> <4EEF4F1E.9080104@codemonkey.ws> <4EEF5263.8070004@redhat.com> <4EEF53D1.5040302@codemonkey.ws> In-Reply-To: <4EEF53D1.5040302@codemonkey.ws> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 01/23] memory: introduce memory_region_find() List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Stefano Stabellini , xen-devel@lists.xensource.com, qemu-devel@nongnu.org, kvm@vger.kernel.org, "Michael S. Tsirkin" On 12/19/2011 05:10 PM, Anthony Liguori wrote: > On 12/19/2011 09:04 AM, Avi Kivity wrote: >> On 12/19/2011 04:50 PM, Anthony Liguori wrote: >>>> +static int cmp_flatrange_addr(const void *_addr, const void *_fr) >>>> +{ >>>> + const AddrRange *addr =3D _addr; >>>> + const FlatRange *fr =3D _fr; >>> >>> >>> Please don't prefix with an underscore. >> >> Why not? It's legal according to the standards, if that's your concer= n >> (only _[_A-Z]+ are reserved). > > http://www.gnu.org/s/hello/manual/libc/Reserved-Names.html > > "In addition to the names documented in this manual, reserved names > include all external identifiers (global functions and variables) that > begin with an underscore (=91_=92)" > > Now that might just mean that you're shadowing a global name, so maybe > that's okay, but I think it's easier to just enforce a consistent rule > of, "don't start identifiers with an underscore". I rather like the pattern void callback(void *_foo) { Foo *foo =3D _foo; ... } If the consensus is that we don't want it, I'll change it, but I do think it's useful. >>>> +MemoryRegionSection memory_region_find(MemoryRegion *address_space, >>>> + target_phys_addr_t addr, >>>> uint64_t size); >>> >>> >>> Returning structs by value is a bit unexpected. >> >> It's just prejudice, here's the call sequence: > > It's not about whether it's fast or slow. It's just unexpected. It's plain C, I don't see why it's so unexpected. > > Instead of returning a NULL pointer on error, you set .mr to NULL if > an error occurs (which isn't documented by the comment btw).=20 > Returning a pointer, or taking a pointer and returning a 0/-1 return > value makes for a more consistent semantic with the rest of the code > base. > How can I return a pointer? If I allocate it, someone has to free it.=20 If I pass it as a parameter, we end up with a silly looking calling convention. If I return an error code, the caller has to set up an additional variable. The natural check is section.size which is always meaningful - memory_region_find() returns a subrange of the input, which may be zero. You're right that I should document it (and I should use it consistently). --=20 error compiling committee.c: too many arguments to function