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