From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60730) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UsW4I-0000sF-HC for qemu-devel@nongnu.org; Fri, 28 Jun 2013 06:38:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UsW4F-0005XV-E7 for qemu-devel@nongnu.org; Fri, 28 Jun 2013 06:38:18 -0400 Received: from mx1.redhat.com ([209.132.183.28]:56167) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UsW4F-0005XL-6V for qemu-devel@nongnu.org; Fri, 28 Jun 2013 06:38:15 -0400 Message-ID: <51CD681A.6030500@redhat.com> Date: Fri, 28 Jun 2013 12:40:26 +0200 From: Laszlo Ersek MIME-Version: 1.0 References: <51CD35C4.5000802@redhat.com> In-Reply-To: <51CD35C4.5000802@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH v4 06/10] qemu-ga: Add Windows VSS provider to quiesce applications on fsfreeze List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: "libaiqing@huawei.com" , "mdroth@linux.vnet.ibm.com" , "stefanha@gmail.com" , "qemu-devel@nongnu.org" , "lcapitulino@redhat.com" , "vrozenfe@redhat.com" , Tomoki Sekiyama , Seiji Aguchi , "areis@redhat.com" On 06/28/13 09:05, Paolo Bonzini wrote: > Il 28/06/2013 00:25, Tomoki Sekiyama ha scritto: >>>>>>>>>> +STDMETHODIMP CQGAVssProviderFactory::CreateInstance( >>>>>>>>>> + IUnknown *pUnknownOuter, REFIID iid, void **ppv) >>>>>>>>>> +{ >>>>>>>>>> + if (pUnknownOuter) { >>>>>>>>>> + return CLASS_E_NOAGGREGATION; >>>>>>>>>> + } >>>>>>>>>> + CQGAVssProvider *pObj =3D new CQGAVssProvider; >>>>>>>>>> + if (!pObj) { >>>>>>>>>> + return E_OUTOFMEMORY; >>>>>>>>>> + } >>>> >>>> (We generally assume that memory allocation never fails.) >> Ah, OK... >=20 > Actually, we do because we use g_malloc/g_free. The functions exit on > memory allocation failure. I'm not sure the same is true of the new > operator... doesn't it throw an exception on allocation failure (that's > what I vaguely remember)? It throws std::bad_alloc on failure. There's another new operator (the nothrow form) thar returns 0 on failure. 18.4.1.1 Single-object forms [lib.new.delete.single]; p9: [Example: T* p1 =3D new T; // throws bad_alloc if it fails T* p2 =3D new(nothrow) T; // returns 0 if it fails =97end example] ( "nothrow" in the above is std::nothrow, an object with static storage duration, of type "nothrow_t" -- it's a dummy argument so that operator new() can have to prototypes. It is passed by const reference. 18.4 Dynamic memory management [lib.support.dynamic]; p1: namespace std { class bad_alloc; struct nothrow_t {}; extern const nothrow_t nothrow; /* ... */ } void* operator new(std::size_t size) throw(std::bad_alloc); void* operator new(std::size_t size, const std::nothrow_t&) throw(); ) As far as I can remember, older C++ implementations had problems with bad_alloc. I believe though that any gcc release frome after the stone age should handle this correctly; see also -fcheck-new. Of course I have no idea what happens when a C++ exception tries to propagate past a "DLL boundary". > Also, this is not running in the context of qemu-ga, so I think it is > better to be more conservative and trap memory allocation failure. In that case other "new" calls must assume the nothrow form too, plus other allocation functions should be checked as well (eg. SysAllocStringLen(), although its only use might be in the function that Tomoki plans to remove anyway). Laszlo