Re: SunOS4 port

Поиск
Список
Период
Сортировка
От Tatsuo Ishii
Тема Re: SunOS4 port
Дата
Msg-id 20011206103957H.t-ishii@sra.co.jp
обсуждение исходный текст
Ответ на Re: SunOS4 port  (Bruce Momjian <pgman@candle.pha.pa.us>)
Ответы Re: SunOS4 port  (Peter Eisentraut <peter_e@gmx.net>)
Список 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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Doug McNaught
Дата:
Сообщение: Re: Licensing
Следующее
От: Karel Zak
Дата:
Сообщение: Re: date formatting and tab-complete patch