On 2017-04-09 19:20:27 -0400, Tom Lane wrote: > Andres Freund <and...@anarazel.de> writes: > > For a while I've been getting warnings like > > /home/andres/src/postgresql/src/backend/utils/adt/inet_cidr_ntop.c: In > > function ‘inet_cidr_ntop_ipv6’: > > /home/andres/src/postgresql/src/backend/utils/adt/inet_cidr_ntop.c:205:11: > > warning: left shift of negative value [-Wshift-negative-value] > > m = ~0 << (8 - b); > > ^~ > > I imagine forcing the LHS to unsigned would silence that, though you'd > have to be careful that the sign extension (widening) happened before > you changed the value to unsigned, in the int64 cases. It's a bit odd > though that it seems to think ~0 is signed.
Hm, why's that odd? By default integers are signed, and ~ doesn't change signedness? > > If I understand C99 correctly, the behaviour of a left-shift of a > > negative number is undefined (6.5.7 4.). > > As I read that, it's only "undefined" if overflow would occur (ie > the sign bit would change). Your compiler is being a useless annoying > nanny, but that seems to be the in thing for compiler authors these > days. "The result of E1 << E2 is E1 left-shifted E2 bit positions; vacated bits are filled with zeros. If E1 has an unsigned type, the value of the result is E1 × 2 E2 , reduced modulo one more than the maximum value representable in the result type. If E1 has a signed type and nonnegative value, and E1 × 2 E2 is representable in the result type, then that is the resulting value; otherwise, the behavior is undefined." As I read this it's defined iff E1 is signed, nonnegative *and* the the result of the shift is representable in the relevant type. That seems, uh, a bit restrictive, but that seems to be the only reading? Note that the otherwise is preceded by a semicolon... - Andres -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
