On 2017-Jan-29, at 8:51 PM, Justin Hibbits <chmeeedalf at gmail.com> wrote:
> 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 FYI: Here is what gcc6 does with -Wpedantic: # gcc6 -std=c99 -Wpedantic signed_test.c signed_test.c: In function 'main': signed_test.c:4:10: warning: overflow in implicit constant conversion [-Woverflow] sc = 1<<7; ^ signed_test.c:5:10: warning: overflow in implicit constant conversion [-Woverflow] sc = 1U<<7; ^~ This was for: # more signed_test.c int main () { signed char sc; sc = 1<<7; sc = 1U<<7; sc = (signed char) (1U<<7); } Without -Wpedantic it is silent about all 3 assignments. -Wpedantic makes no difference to clang: # clang -std=c99 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 = 1<<7; ~ ~^~~ 1 warning generated. # clang -std=c99 -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 = 1<<7; ~ ~^~~ 1 warning generated. === Mark Millard markmi at dsl-only.net _______________________________________________ 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"
