From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
---|---|
To: | Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp> |
Cc: | <pgman(at)candle(dot)pha(dot)pa(dot)us>, <tgl(at)sss(dot)pgh(dot)pa(dot)us>, <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: SunOS4 port |
Date: | 2001-12-19 18:46:40 |
Message-ID: | Pine.LNX.4.30.0112191836150.635-100000@peter.localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tatsuo Ishii writes:
> The reason why non-8bit clean memcmp has not been a problem with
> SunOS4 port was just memcmp's return value was evaluated 0 or not.
> However, bit data type implementation uses the fact that whether the
> value is greater than or less than 0 and bit type appeared since 7.1.
> I guess that is the reason why we don't see any memcmp problem before
> 7.1.
The return value of memcmp() is also used by bytea and oidvector. As long
as you don't need comparison results, and memcmp gives wrong results
consistently then you might even get away with it, but a disfunctional
oidvector cannot be taken as lightly as the bit types.
I've put the SunOS 4 platform under "Unsupported" with the comment
"memcmp() does not work correctly, so probably not reliable". Seasoned
SunOS 4 users might know what that implies.
--
Peter Eisentraut peter_e(at)gmx(dot)net
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2001-12-19 18:53:47 | Re: SunOS4 port |
Previous Message | Peter Eisentraut | 2001-12-19 18:46:17 | Re: SunOS patch for memcmp() |