From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39938) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zhhgv-0002p2-RK for qemu-devel@nongnu.org; Thu, 01 Oct 2015 13:30:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zhhgp-0002jr-CV for qemu-devel@nongnu.org; Thu, 01 Oct 2015 13:30:49 -0400 Received: from mx1.redhat.com ([209.132.183.28]:54234) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zhhgo-0002hz-Qs for qemu-devel@nongnu.org; Thu, 01 Oct 2015 13:30:42 -0400 References: <1443558863-26132-1-git-send-email-ehabkost@redhat.com> <1443558863-26132-2-git-send-email-ehabkost@redhat.com> <560BE355.60901@redhat.com> <560C44F4.6030200@twiddle.net> <560D3A8B.4020603@redhat.com> <560D6857.1030501@redhat.com> From: Paolo Bonzini Message-ID: <560D6DBD.9010305@redhat.com> Date: Thu, 1 Oct 2015 19:30:37 +0200 MIME-Version: 1.0 In-Reply-To: <560D6857.1030501@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 1/2] target-i386: Use 1UL for bit shift List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Laszlo Ersek , Peter Maydell , Richard Henderson Cc: Eduardo Habkost , QEMU Developers On 01/10/2015 19:07, Laszlo Ersek wrote: > > In addition, C89 didn't say at all what the result was for signed dat= a > > types, so technically we could compile QEMU with -std=3Dgnu89 (the de= fault > > until GCC5) and call it a day. > >=20 > > Really the C standard should make this implementation-defined. >=20 > Obligatory link: http://blog.regehr.org/archives/1180 Many ideas in there are good (e.g. mem*() being defined for invalid argument and zero lengths, and of course item 7 which is the issue at hand). In many cases it's also good to change undefined behavior to unspecified values, however I think that goes too far. For example I'm okay with signed integer overflow being undefined behavior, and I also disagree with "It is permissible to compute out-of-bounds pointer values including performing pointer arithmetic on the null pointer". Using uintptr_t is just fine. Also strict aliasing improves performance noticeably at least on some kind of code. The relaxation of strict aliasing that GCC does with unions would be a useful addition to the C standard, though. Paolo