Re: [HACKERS] inet data type regression test fails - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: [HACKERS] inet data type regression test fails
Date
Msg-id 199903151525.KAA13750@candle.pha.pa.us
Whole thread Raw
In response to inet data type regression test fails  (Tatsuo Ishii <t-ishii@sra.co.jp>)
Responses Re: [HACKERS] inet data type regression test fails
List pgsql-hackers
> Hi all,
> 
> 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.  When you say
1 or 2, how do you get those values?

--  Bruce Momjian                        |  http://www.op.net/~candle maillist@candle.pha.pa.us            |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] VACUUM ANALYZE problem on linux
Next
From: Oleg Broytmann
Date:
Subject: Re: [HACKERS] VACUUM ANALYZE problem on linux