Bug#561249: Spurious warning with -Wconversion (uint16_t/htons) in -O2 mode

[Falk Hueffner <falk@debian.org>]

reassign 561249 libc6-dev
thanks

On Wed, Dec 16, 2009 at 10:54:21AM +0100, Aurelien Jarno wrote:
> Eric Estievenart a écrit :
> > The bug may be rather in libc6-dev, which defines:
> > htons to __bswap16 if optimize && little endian,
> > and __bswap16 in bits/byteswap.h
> > # define __bswap_16(x) \
> >      (__extension__                                                           \
> >       ({ register unsigned short int __v, __x = (x);                          \
> >          if (__builtin_constant_p (__x))                                      \
> >            __v = __bswap_constant_16 (__x);                                   \
> >          else                                                                 \
> >            __asm__ ("rorw $8, %w0"                                            \
> >                     : "=r" (__v)                                              \
> >                     : "0" (__x)                                               \
> >                     : "cc");                                                  \
> >          __v; }))
> > I'm not expert enough with gcc inline assembly to guess what the exact
> > problem is, but it is definitely in this macro or the way gcc handles it,
> > but since gcc <= 4.2 noes not show any warning in optimize it, I'd rather
> > think it is a gcc (4.3 & 4.4) regression
> 
> The problem is not the asm code, but actually the shift that comes from
> __bswap_constant_16(). The problem can be reproduced with this simple code:
> 
> #include <stdint.h>
> 
> void test ()
> {
>   uint16_t s = 123;
>   uint16_t t = (s & 0xff) << 8;
>   uint16_t u = ((uint8_t)s) << 8;
> }
> 
> It looks like the << operator implicitely convert the value to int. I
> haven't checked the standards about that.

Any arithmetic operation causes promotion of the operands from
unsigned short to int first. So the warning is correct.

  Falk