svn commit: r312977 - head/sys/dev/adb

[Justin Hibbits]

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