Date: Sun, 29 Jan 2017 22:51:36 -0600 From: Justin Hibbits <chmeeedalf@gmail.com> To: Mark Millard <markmi@dsl-only.net> Cc: svn-src-head@freebsd.org Subject: Re: svn commit: r312977 - head/sys/dev/adb Message-ID: <D0496CDE-360C-4BC2-80B7-80844DB55DD1@gmail.com> In-Reply-To: <588CB781-A470-4101-8108-ADAD34525422@dsl-only.net> References: <588CB781-A470-4101-8108-ADAD34525422@dsl-only.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Mark, On Jan 29, 2017, at 9:42 PM, Mark Millard wrote: >> Author: jhibbits >> Date: Mon Jan 30 02:32:33 2017 >> New Revision: 312977 >> URL: >> https://svnweb.freebsd.org/changeset/base/312977 >> >> >> Log: >> Force the setting of bit 7 in the sysmouse packet byte 1 to be >> unsigned. >> >> Clang complains about the shift of (1 << 7) into a int8_t changing >> the value: >> >> warning: implicit conversion from 'int' to 'int8_t' (aka 'signed >> char') changes >> value from 128 to -128 [-Wconstant-conversion] >> >> Squash this warning by forcing clang to see it as an unsigned bit. >> >> 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. > > [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.] > > An FYI/explanation of sorts. . . > > 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: > > (After the cases of value-representable-so-value-is-unchanged > and new-type-is-unsigned, quoting:) > >> 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. > > 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. > > (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.) 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. - Justin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?D0496CDE-360C-4BC2-80B7-80844DB55DD1>