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

From Thomas G. Lockhart
Subject Re: [HACKERS] inet data type regression test fails
Date
Msg-id 36D21736.88A7EF59@alumni.caltech.edu
Whole thread Raw
In response to Re: [HACKERS] 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
> what is the correct result of
>   (0xffffffff >> ip_bits()) if ip_bits() == 32?
> > 1. 0x0
> > 2. 0xffffffff (actually does nothing)

In both cases, it does something. I haven't looked it up, but I suspect
that this is an implementation-defined result, since you are seeing the
results of right-shifting the sign bit *or* the high bit downward. On
some systems it does not propagate, and on others it does.

Have you tried coercing 0xffffffff to be a signed char? The better
solution is probably to mask the result before comparing, or handling
shifts greater than 31 as a special case. For example,
 /* It's an IP V4 address: */ int addr = htonl(ntohl(ip_v4addr(ip)) | (0xffffffff >> ip_bits(ip)));

becomes
 /* It's an IP V4 address: */ int addr = htonl(ntohl(ip_v4addr(ip)); if (ip_bits(ip) < sizeof(addr))   addr |=
(0xffffffff>> ip_bits(ip)));
 

or something like that...
                       - Tom


pgsql-hackers by date:

Previous
From: RHS Linux User
Date:
Subject: Re: [HACKERS] Updated developers list
Next
From: "Thomas G. Lockhart"
Date:
Subject: Re: [HACKERS] Re: [COMMITTERS] 'pgsql/src/test/regress/expected rules.out'