From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:49978) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R964G-0007xK-Nh for qemu-devel@nongnu.org; Wed, 28 Sep 2011 22:09:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R964F-0003X6-BR for qemu-devel@nongnu.org; Wed, 28 Sep 2011 22:09:44 -0400 Received: from e23smtp03.au.ibm.com ([202.81.31.145]:55066) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R964E-0003VT-PS for qemu-devel@nongnu.org; Wed, 28 Sep 2011 22:09:43 -0400 Received: from d23relay03.au.ibm.com (d23relay03.au.ibm.com [202.81.31.245]) by e23smtp03.au.ibm.com (8.14.4/8.13.1) with ESMTP id p8T23so9015158 for ; Thu, 29 Sep 2011 12:03:54 +1000 Received: from d23av01.au.ibm.com (d23av01.au.ibm.com [9.190.234.96]) by d23relay03.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p8T29NZN2207848 for ; Thu, 29 Sep 2011 12:09:25 +1000 Received: from d23av01.au.ibm.com (loopback [127.0.0.1]) by d23av01.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p8T29MHJ014153 for ; Thu, 29 Sep 2011 12:09:22 +1000 Received: from [127.0.0.1] ([9.115.127.1]) by d23av01.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p8T29Knm012501 for ; Thu, 29 Sep 2011 12:09:22 +1000 Message-ID: <4E83D320.305@linux.vnet.ibm.com> Date: Thu, 29 Sep 2011 10:08:32 +0800 From: Wayne Xia MIME-Version: 1.0 References: <4E8296A1.1000407@linux.vnet.ibm.com> <4E82DE42.6000708@siemens.com> In-Reply-To: <4E82DE42.6000708@siemens.com> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [RFC] potential risk for macro QTAILQ_INSERT_BEFORE List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org =D3=DA 2011-9-28 16:43, Jan Kiszka =D0=B4=B5=C0: > On 2011-09-28 05:38, Wayne Xia wrote: >> Hi, during my coding, I found macro a bit different from other >> QTAIL macros. >> >> QTAILQ_INSERT_AFTER was defined as: >> ----------------------------------------------------------- >> #define QTAILQ_INSERT_AFTER(head, listelm, elm, field) do { = \ >> if (((elm)->field.tqe_next =3D (listelm)->field.tqe_next) !=3D= NULL)\ >> (elm)->field.tqe_next->field.tqe_prev =3D = \ >> &(elm)->field.tqe_next; = \ >> else = \ >> (head)->tqh_last =3D&(elm)->field.tqe_next; = \ >> (listelm)->field.tqe_next =3D (elm); = \ >> (elm)->field.tqe_prev =3D&(listelm)->field.tqe_next; = \ >> } while (/*CONSTCOND*/0) >> --------------------------------------------------------- >> QTAILQ_INSERT_BEFORE is defined as following: >> >> #define QTAILQ_INSERT_BEFORE(listelm, elm, field) do { >> (elm)->field.tqe_prev =3D (listelm)->field.tqe_prev; = \ >> (elm)->field.tqe_next =3D (listelm); = \ >> *(listelm)->field.tqe_prev =3D (elm); = \ >> (listelm)->field.tqe_prev =3D&(elm)->field.tqe_next; = \ >> } while (/*CONSTCOND*/0) >> ---------------------------------------------------------- >> >> It did not take care of "head" as QTAILQ_INSERT_AFTER did, so I a= m >> wondering what would happen if I use QTAILQ_INSERT_BEFORE to insert on= e >> element to a queue that have only one element in it, would it happen >> that the queue head pointer is not updated and the real first element >> is lost? Currently some codes in qemu have used this macro. >=20 > The code is fine: a QTAILQ head consists of a dummy entry element that > looks for the first element as if a normal element would precede it. In > contrast, there is no dummy "end element", the last one just points to > NULL. Therefore we need to handle this separately. Thanks Jan, made a test program showing the macro is OK, the dummy element works like a magic. >=20 > Jan >=20 --=20 Best Regards Wayne Xia mail:xiawenc@linux.vnet.ibm.com tel:86-010-82450803