[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: type behavior of sys/endian.h
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:
> 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
Unless we can figure out what gcc's doing, which is maybe not
worthwhile, that's probably true.
David A. Holland
Main Index |
Thread Index |