Re: type behavior of sys/endian.h

[Alan Barrett <apb%cequrux.com@localhost>]

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
warning.

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
implementation-defined".

--apb (Alan Barrett)