tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: type behavior of sys/endian.h

On Sun, 26 Jul 2009, David Holland wrote:
> le16toh(~1)      -> nothing
> le16toh(~1U)     -> "large integer implicitly truncated to unsigned type"
> le16toh(~32767)  -> nothing
> le16toh(~32767U) -> "large integer implicitly truncated to unsigned type"
> le16toh(~32769)  -> "large integer implicitly truncated to unsigned type"
> le16toh(~32769U) -> "large integer implicitly truncated to unsigned type"
> This makes no sense, and I think gcc must be doing something wrong
> internally, more than just printing a not-quite-relevant message. But
> everything involving shorts is aggravating, so maybe not.

Yes, this makes no sense.  In some cases, a signed int is converted to
uint16_t, and in some cases an unsigned int is converted to uint16_t.
Both these cases are well defined, and seem to me not to warrant any

I do not see a "large integer" anywhere (assuming that that term refers
to an integer larger than plain int), except on platforms where int
is 16 bits and the literal constants 32769 is treated as having type
signed long int.  It also seems backwards that gcc gives a warning about
"truncted to signed type" where the input is already unsigned, but not
where the input is signed.

In the cases where gcc does not complain, I would consider it
reasonable to warn "use of ~ operator with signed arguments is

--apb (Alan Barrett)

Home | Main Index | Thread Index | Old Index