From owner-svn-src-all@freebsd.org Fri Jan 19 14:57:04 2018 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 43AEEEB6B2A; Fri, 19 Jan 2018 14:57:04 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (xvm-110-62.dc2.ghst.net [46.226.110.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "theravensnest.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C1BBF677; Fri, 19 Jan 2018 14:57:02 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from c124.sec.cl.cam.ac.uk (c124.sec.cl.cam.ac.uk [128.232.18.124]) (authenticated bits=0) by theravensnest.org (8.15.2/8.15.2) with ESMTPSA id w0JEus8a002213 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 19 Jan 2018 14:56:55 GMT (envelope-from theraven@FreeBSD.org) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: svn commit: r328159 - head/sys/modules From: David Chisnall In-Reply-To: Date: Fri, 19 Jan 2018 14:56:54 +0000 Cc: Benjamin Kaduk , src-committers , svn-src-all@freebsd.org, svn-src-head@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <244014BB-C492-48A9-9F28-0A5E713DE5EB@FreeBSD.org> References: <201801190434.w0J4Y6i7086677@repo.freebsd.org> To: cem@freebsd.org X-Mailer: Apple Mail (2.3273) X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jan 2018 14:57:04 -0000 On 19 Jan 2018, at 05:07, Conrad Meyer wrote: >=20 > The spec says the behavior is undefined; not that the compiler has to > produce a warning or error message. The compiler *does* get to > arbitrarily decide what it wants to do when it encounters UB. It is > wholly free to implement this particular UB with the logical result > and no warning/error. First, you are not correct that the only logical outcome of a shift of = greater than the width of a type is 0. In C, a right-shift of a signed = type propagates the sign bit. Right shifting a negative 32-bit int by = 16 and then again by 16 is not undefined behaviour (though doing the = shift as a single operation is) and will give you a value of -1. The spec says that it is undefined, because on some architectures there = is a right-shift instructions that produces non-zero values when = instructed to shift right more than the width of the value. A shift of greater than the width of the size requires special handling = in the compiler for some architectures and is always a logic error. = This gives two cases: Either the compiler can statically prove that the = value is too large, or it is not. Because the C spec says that it is = undefined, if the compiler cannot prove that the value is too large, = then it is free to assume that it isn=E2=80=99t. This means that the = back end can always emit instructions that produce unspecified values = for larger ranges. The compiler is free to do anything it wants in the case of UB, = including make monkeys fly out of your nose. Telling you that you have = done something obviously stupid is generally considered better than just = generating wrong code. David