Re: type behavior of sys/endian.h

[Matt Thomas <matt%3am-software.com@localhost>]

On Jul 25, 2009, at 9:41 PM, David Holland wrote:

> On Wed, Jul 22, 2009 at 01:12:42AM +0200, Joerg Sonnenberger wrote:
> > > Or maybe they should be made inline functions instead so they don't
> > > fail silently if passed pointers.
> >
> > So we have two approach:
> > (1) Cast the value directly.
> > (2) Use inline functions.
> >
> > When doing (2), fxp(4) doesn't compile as the follow construct  
> > triggers
> > a gcc warning:
> >         le16toh(~mask)
> > with mask being some signed small constant. This even happens if  
> > mask is
> > unsigned or already of the correct width.
>
> 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.

This make perfect sense to me.  The two values without a warning
convert from int to short with no loss of representation.  All the
other have value outside -32768..32767 and thus must be truncated to  
fit.

The warning happens when N != (short) N or N != (unsigned short) N
depending on whether N is unsigned.