Re: [HACKERS] inet data type regression test fails

From: "Thomas G(dot) Lockhart" <lockhart(at)alumni(dot)caltech(dot)edu>
To: t-ishii(at)sra(dot)co(dot)jp
Cc: hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] inet data type regression test fails
Date: 1999-02-23 02:49:26
Message-ID: 36D21736.88A7EF59@alumni.caltech.edu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas G. Lockhart 1999-02-23 02:58:44 Re: [HACKERS] Re: [COMMITTERS] 'pgsql/src/test/regress/expected rules.out'
Previous Message RHS Linux User 1999-02-23 02:31:47 Re: [HACKERS] Updated developers list