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

From Tatsuo Ishii
Subject Re: [HACKERS] inet data type regression test fails
Date
Msg-id 199905110122.KAA28976@srapc451.sra.co.jp
Whole thread Raw
In response to Re: [HACKERS] inet data type regression test fails  (Taral <taral@taral.net>)
Responses Re: [HACKERS] inet data type regression test fails
List pgsql-hackers
>On Tue, 11 May 1999, Tatsuo Ishii wrote:
>
>>         unsigned long mask = 0xffffffff;
>> 
>>         if (ip_bits(ip) < 32)
>>             mask >>= ip_bits(ip);
>>         addr = htonl(ntohl(ip_v4addr(ip)) | mask);
>
>That's wrong too. There needs to be:
>
>else
>    mask = 0;
>
>Taral

No. it is expected addr == 0xffffffff if ip_bits() returns >= 32. This 
is how the function (network_broadcast()) is made.
See included posting.

>From: Tatsuo Ishii <t-ishii@sra.co.jp>
>To: hackers@postgreSQL.org
>Subject: [HACKERS] inet data type regression test fails
>Date: Mon, 22 Feb 1999 11:54:39 +0900
>
>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?
>---
>Tatsuo Ishii
>
>


pgsql-hackers by date:

Previous
From: Taral
Date:
Subject: Re: [HACKERS] inet data type regression test fails
Next
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] Optimization info