Re: [BUGS] Bug in create operator and/or initdb

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Steve Atkins <steve(at)blighty(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, paul(at)vix(dot)com
Subject: Re: [BUGS] Bug in create operator and/or initdb
Date: 2005-01-31 17:16:26
Message-ID: 20593.1107191786@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

Steve Atkins <steve(at)blighty(dot)com> writes:
> The cidr type, including it's external interface, is simply broken.

That is a large claim that I don't think you have demonstrated.
The only one of your examples that seems to me to contradict the
documentation is this one:

steve=# select '224.0.0.0'::cidr;
cidr
-------------
224.0.0.0/4

which should be /32 according to what the docs say:

: If y is omitted, it is calculated using assumptions from the older
: classful network numbering system, except that it will be at least large
: enough to include all of the octets written in the input.

The bogus netmask is in turn responsible for this case:

steve=# select '224.10.0.0'::cidr;
ERROR: invalid cidr value: "224.10.0.0"
DETAIL: Value has bits set to right of mask.

Looking at the source code, there seems to be a special case for "class D"
network numbers that causes the code not to extend y to cover the
supplied inputs:

/* If no CIDR spec was given, infer width from net class. */
if (bits == -1)
{
if (*odst >= 240) /* Class E */
bits = 32;
else if (*odst >= 224) /* Class D */
bits = 4;
else if (*odst >= 192) /* Class C */
bits = 24;
else if (*odst >= 128) /* Class B */
bits = 16;
else /* Class A */
bits = 8;
/* If imputed mask is narrower than specified octets, widen. */
if (bits >= 8 && bits < ((dst - odst) * 8))
^^^^^^^^^
bits = (dst - odst) * 8;
}

I think the test for "bits >= 8" should be removed. Does anyone know
why it's there?

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2005-01-31 17:29:12 Re: Template1 is locked when pgAdminIII is open
Previous Message Dave Page 2005-01-31 16:59:54 Re: Template1 is locked when pgAdminIII is open

Browse pgsql-hackers by date

  From Date Subject
Next Message Josh Berkus 2005-01-31 17:40:29 Re: [pgsql-hackers] Patent issues and 8.1
Previous Message Marc G. Fournier 2005-01-31 17:03:19 Bundles running late ...