Re: [HACKERS] inet data type regression test fails

> > The inet regression test has been failed on my LinuxPPC. While
> > investigating the reason, I found a code that doesn't work on
> > LinuxPPC. From network_broadcast() in utils/adt/network.c:
> > 
> > int    addr = htonl(ntohl(ip_v4addr(ip)) | (0xffffffff >> ip_bits(ip)));
> > 
> > Here ip_bits() returns from (unsigned char)0 to 32. My question is:
> > what is the correct result of (0xffffffff >> ip_bits())?
> > 
> > 1. 0x0
> > 2. 0xffffffff (actually does nothing)
> > 
> > LinuxPPC is 1. FreeBSD and Solaris are 2. network_broadcast() seems to
> > expect 2. My guess is shifting over 32bit against a 32bit integer is
> > not permitted and the result is platform depedent. If this would true,
> > it could be said that network_broadcast() has a portabilty
> > problem. Comments?
> 
> If 0xffffff is unsigned, it should allow the right shift.  

No. it does not depend on if 0xffffffff is signed or not.  Suppose a
is signed and b is unsigned. In "a >> b", before doing an actual
shifting operation, a is "upgraded" to unsigned by the compiler.

>When you say
> 1 or 2, how do you get those values?

You could observe the "32 bit shift efect" I mentioned in the previous
mail by running following small program.

main()
{ unsigned char c; for (c = 0;c <=32;c++) {   printf("shift: %d result: 0x%08x\n",c,0xffffffff >> c); }
}
---
Tatsuo Ishii