Re: type behavior of sys/endian.h

[David Holland <dholland-tech%netbsd.org@localhost>]

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.

 > When doing (1), the supposed issue of "What happens if I use a pointer?"
 > problem exists. Given the use of bus_dma and bus_space, this is highly
 > likely to be a real bug. It will also show up by building on different
 > system type (LP64 vs ILP32).
 > 
 > I think the burden of artifical casts for (2) is worse than the gain from
 > (1).

Unless we can figure out what gcc's doing, which is maybe not
worthwhile, that's probably true.

-- 
David A. Holland
dholland%netbsd.org@localhost