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
_______________________________________________
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
