From owner-svn-src-head@freebsd.org Mon Jan 30 05:15:37 2017 Return-Path: Delivered-To: svn-src-head@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 E946CCC7A39 for ; Mon, 30 Jan 2017 05:15:37 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-72.reflexion.net [208.70.210.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 903863CF for ; Mon, 30 Jan 2017 05:15:37 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 29644 invoked from network); 30 Jan 2017 05:17:19 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 30 Jan 2017 05:17:19 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.20.1) with SMTP; Mon, 30 Jan 2017 00:15:35 -0500 (EST) Received: (qmail 19072 invoked from network); 30 Jan 2017 05:15:34 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 30 Jan 2017 05:15:34 -0000 Received: from [192.168.1.111] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 1BE5AEC77A4; Sun, 29 Jan 2017 21:15:34 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: svn commit: r312977 - head/sys/dev/adb From: Mark Millard In-Reply-To: Date: Sun, 29 Jan 2017 21:15:33 -0800 Cc: svn-src-head@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <588CB781-A470-4101-8108-ADAD34525422@dsl-only.net> To: Justin Hibbits X-Mailer: Apple Mail (2.3259) X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2017 05:15:38 -0000 On 2017-Jan-29, at 8:51 PM, Justin Hibbits = wrote: > Hi Mark, >=20 > On Jan 29, 2017, at 9:42 PM, Mark Millard wrote: >=20 >>> Author: jhibbits >>> Date: Mon Jan 30 02:32:33 2017 >>> New Revision: 312977 >>> URL: >>> https://svnweb.freebsd.org/changeset/base/312977 >>>=20 >>>=20 >>> Log: >>> Force the setting of bit 7 in the sysmouse packet byte 1 to be = unsigned. >>>=20 >>> Clang complains about the shift of (1 << 7) into a int8_t changing = the value: >>>=20 >>> warning: implicit conversion from 'int' to 'int8_t' (aka 'signed = char') changes >>> value from 128 to -128 [-Wconstant-conversion] >>>=20 >>> Squash this warning by forcing clang to see it as an unsigned bit. >>>=20 >>> This seems odd, given that it's still a conversion of 128->-128, but = I'm >>> guessing the explicit unsigned attribute notifies clang that sign = really doesn't >>> matter in this case. >>=20 >> [The following is based just on the C standard, not POSIX >> or other standards that may also be involved from FreeBSD's >> point of view.] >>=20 >> An FYI/explanation of sorts. . . >>=20 >> In the C11 standard (e.g., since I have it handy) having the >> new type be signed has the rule for signed and unsigned integer >> implicit conversions between the types: >>=20 >> (After the cases of value-representable-so-value-is-unchanged >> and new-type-is-unsigned, quoting:) >>=20 >>> Otherwise, the new type is signed and the value cannot be = represented >>> in it; either the result is implementation-defined or an >>> implementation-defined signal is raised. >>=20 >> So while 1U use may make the compiler(s) tested be quiet it still = leaves >> the code in implementation-defined territory where different starting >> types for the same value are allowed to have different results. But >> they are not required to and compiler releases could change the >> classification --and if there are messages from the compiler or not. >> Bit patterns need not be preserved for the sign-bit and/or >> value-carrying bits in the new type vs. the old type. >>=20 >> (By contrast a new type being unsigned is defined with a = mathematically >> specific/unique result and so a specific bit pattern for the >> value-carrying bits, ignoring trap representations and other pad bits >> if they exist.) >=20 > Thanks for the explanation. I had a feeling I was in undefined and/or = implementation defined behavior with this, and was surprised that it = squashed the warning with such a trivial change. I think we're safe = here, though, since the PowerPC ABI and Power ABI are well defined. >=20 > - Justin FYI: Here is what gcc6 does with -Wpedantic: # gcc6 -std=3Dc99 -Wpedantic signed_test.c signed_test.c: In function 'main': signed_test.c:4:10: warning: overflow in implicit constant conversion = [-Woverflow] sc =3D 1<<7; ^ signed_test.c:5:10: warning: overflow in implicit constant conversion = [-Woverflow] sc =3D 1U<<7; ^~ This was for: # more signed_test.c int main () { signed char sc; sc =3D 1<<7; sc =3D 1U<<7; sc =3D (signed char) (1U<<7); } Without -Wpedantic it is silent about all 3 assignments. -Wpedantic makes no difference to clang: # clang -std=3Dc99 signed_test.c signed_test.c:4:11: warning: implicit conversion from 'int' to 'signed = char' changes value from 128 to -128 [-Wconstant-conversion] sc =3D 1<<7; ~ ~^~~ 1 warning generated. # clang -std=3Dc99 -Wpedantic signed_test.c signed_test.c:4:11: warning: implicit conversion from 'int' to 'signed = char' changes value from 128 to -128 [-Wconstant-conversion] sc =3D 1<<7; ~ ~^~~ 1 warning generated. =3D=3D=3D Mark Millard markmi at dsl-only.net