From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:45744) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UL9Oa-00088P-Vc for qemu-devel@nongnu.org; Thu, 28 Mar 2013 05:45:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UL9OZ-0000kW-Bb for qemu-devel@nongnu.org; Thu, 28 Mar 2013 05:45:20 -0400 Date: Thu, 28 Mar 2013 10:45:11 +0100 From: Stefan Hajnoczi Message-ID: <20130328094511.GF24910@stefanha-thinkpad.redhat.com> References: <1364410030-24008-1-git-send-email-rth@twiddle.net> <515383E2.7010408@suse.de> <51539468.6060301@twiddle.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <51539468.6060301@twiddle.net> Subject: Re: [Qemu-devel] [Qemu-trivial] [PATCH] vmxnet: Don't use bswap_64 for constants List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Richard Henderson Cc: qemu-trivial@nongnu.org, Andreas =?iso-8859-1?Q?F=E4rber?= , qemu-devel@nongnu.org On Wed, Mar 27, 2013 at 05:52:56PM -0700, Richard Henderson wrote: > On 2013-03-27 16:42, Andreas Färber wrote: > >Am 27.03.2013 19:47, schrieb Richard Henderson: > >>This macro is used in the context of defining enum values. > >>We can't use a function call in that case. > >> > >>Cc: qemu-trivial@nongnu.org > >>Signed-off-by: Richard Henderson > >>--- > >> hw/vmxnet3.h | 10 +++++++++- > >> 1 file changed, 9 insertions(+), 1 deletion(-) > >> > >>diff --git a/hw/vmxnet3.h b/hw/vmxnet3.h > >>index 7db0c8f..cd9ac85 100644 > >>--- a/hw/vmxnet3.h > >>+++ b/hw/vmxnet3.h > >>@@ -37,7 +37,15 @@ > >> #define __packed QEMU_PACKED > >> > >> #if defined(HOST_WORDS_BIGENDIAN) > >>-#define const_cpu_to_le64(x) bswap_64(x) > >>+#define const_cpu_to_le64(x) \ > >>+ (((x & 0x00000000000000ffULL) << 56) | \ > >>+ ((x & 0x000000000000ff00ULL) << 40) | \ > >>+ ((x & 0x0000000000ff0000ULL) << 24) | \ > >>+ ((x & 0x00000000ff000000ULL) << 8) | \ > >>+ ((x & 0x000000ff00000000ULL) >> 8) | \ > >>+ ((x & 0x0000ff0000000000ULL) >> 24) | \ > >>+ ((x & 0x00ff000000000000ULL) >> 40) | \ > >>+ ((x & 0xff00000000000000ULL) >> 56)) > > > >Being a macro, shouldn't this better use (x) for operator precedence? > > It doesn't matter for this usage. > > Nor, according to other threads that appeared on the list today, is this > the right fix, since the bswap itself turns out to be bogus. Dmitry said he's sending a fix, will wait for that. Stefan