From: | Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp> |
---|---|
To: | pgman(at)candle(dot)pha(dot)pa(dot)us |
Cc: | tgl(at)sss(dot)pgh(dot)pa(dot)us, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: SunOS4 port |
Date: | 2001-12-06 01:39:57 |
Message-ID: | 20011206103957H.t-ishii@sra.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> > In 7.0 or earlier has a configure check if memcmp is 8 bit clean. In
> > 7.1 someone has removed that test and now we get the failure on
> > SunOS4.
>
> I checked out 7.0 using tag REL7_0_PATCHES, and I see this in configure.in:
>
> AC_FUNC_MEMCMP
>
> and this in configure:
>
> echo "$ac_t""$ac_cv_func_memcmp_clean" 1>&6
> test $ac_cv_func_memcmp_clean = no && LIBOBJS="$LIBOBJS memcmp.${ac_objext}"
>
> However, I don't see any memcmp.c file, nor in 6.5 either. I wonder if
> this was removed from configure.in because it was no longer being used.
You are right. It seems the result of configure check has been never
used in any release. The LIBOBJS variable is not used anywhere in any
Makefile. I wonder why we had that check at all. 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 big question is whether we can backpatch in the memcmp code and have
> it working cleanly in 7.2.
So there is no such a thing "memcmp code", I guess:-) I think we could
give up the bit data type support for SunOS4 port. Apparently SunOS4
users have not been used bit data type. So we do not make
things worse for 7.2 anyway.
--
Tatsuo Ishii
From | Date | Subject | |
---|---|---|---|
Next Message | Karel Zak | 2001-12-06 09:03:22 | Re: date formatting and tab-complete patch |
Previous Message | Doug McNaught | 2001-12-06 00:10:54 | Re: Licensing |