svn commit: r312977 - head/sys/dev/adb
Mark Millard
markmi at dsl-only.net
Mon Jan 30 05:15:38 UTC 2017
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
More information about the svn-src-head
mailing list