Date: Sun, 29 Jan 2017 19:42:00 -0800 From: Mark Millard <markmi@dsl-only.net> To: Justin Hibbits <chmeeedalf@gmail.com>, svn-src-head@freebsd.org Subject: Re: svn commit: r312977 - head/sys/dev/adb Message-ID: <588CB781-A470-4101-8108-ADAD34525422@dsl-only.net>
next in thread | raw e-mail | index | archive | help
> Author: jhibbits > Date: Mon Jan 30 02:32:33 2017 > New Revision: 312977 > URL:=20 > https://svnweb.freebsd.org/changeset/base/312977 >=20 >=20 > Log: > Force the setting of bit 7 in the sysmouse packet byte 1 to be = unsigned. > =20 > Clang complains about the shift of (1 << 7) into a int8_t changing = the value: > =20 > warning: implicit conversion from 'int' to 'int8_t' (aka 'signed = char') changes > value from 128 to -128 [-Wconstant-conversion] > =20 > Squash this warning by forcing clang to see it as an unsigned bit. > =20 > 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.) > Reported by: Mark Millard <markmi AT dsl-only DOT net> > MFC after: 2 weeks >=20 > Modified: > head/sys/dev/adb/adb_mouse.c >=20 > Modified: head/sys/dev/adb/adb_mouse.c > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > --- head/sys/dev/adb/adb_mouse.c Mon Jan 30 02:25:55 2017 = (r312976) > +++ head/sys/dev/adb/adb_mouse.c Mon Jan 30 02:32:33 2017 = (r312977) > @@ -520,7 +520,7 @@ ams_read(struct cdev *dev, struct uio *u > } > } > =20 > - sc->packet[0] =3D 1 << 7; > + sc->packet[0] =3D 1U << 7; > sc->packet[0] |=3D (!(sc->buttons & 1)) << 2; > sc->packet[0] |=3D (!(sc->buttons & 4)) << 1; > sc->packet[0] |=3D (!(sc->buttons & 2)); =3D=3D=3D Mark Millard markmi at dsl-only.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?588CB781-A470-4101-8108-ADAD34525422>