From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KYPHV-0008I0-Iu for qemu-devel@nongnu.org; Wed, 27 Aug 2008 13:58:09 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KYPHT-0008Hm-VW for qemu-devel@nongnu.org; Wed, 27 Aug 2008 13:58:09 -0400 Received: from [199.232.76.173] (port=54426 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KYPHT-0008Hi-Pn for qemu-devel@nongnu.org; Wed, 27 Aug 2008 13:58:07 -0400 Received: from ag-out-0708.google.com ([72.14.246.251]:34429) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KYPHT-0002q5-D6 for qemu-devel@nongnu.org; Wed, 27 Aug 2008 13:58:07 -0400 Received: by ag-out-0708.google.com with SMTP id 31so7131906agc.5 for ; Wed, 27 Aug 2008 10:58:06 -0700 (PDT) Message-ID: <48B5957F.3050000@codemonkey.ws> Date: Wed, 27 Aug 2008 12:57:19 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [patch] add byteordered types References: <48B53E23.5040107@redhat.com> <200808271456.57273.paul@codesourcery.com> <48B56645.60206@redhat.com> <20080827.084738.-674761106.imp@bsdimp.com> <48B56D8D.7050002@redhat.com> <48B5778E.8000709@codemonkey.ws> <48B57EB9.2050106@redhat.com> In-Reply-To: <48B57EB9.2050106@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann Cc: qemu-devel@nongnu.org, Paul Brook Gerd Hoffmann wrote: > Anthony Liguori wrote: > >> Personally, I dislike the whole struct thing. I even further dislike >> having multiple sets of conversion functions that are used in different >> places in the code. >> >> Are we sure that this is something that we want to do? >> > > As far I know this struct trick is the only way to have gcc check access > to variables with an specific byteorder is done the correct way. Avi > sguuested that and I also think this checking would be useful. I could > live without that though if there is an agreement that we'll just stick > with the current, unchecked cpu_to_ functions. > Yeah, AFAIK, it's the only way to enforce this sort of thing but it's also ugly. If we were starting from scratch, I could see the value in it but there's already a ton of code that's not going to be using this mechanism that noone is going to convert. That makes me think there isn't going to be a lot of value in it and will lead to a lot of overall confusion. Regards, Anthony Liguori > cheers, > Gerd > > >