Re: Solaris testers wanted for strxfrm() behavior

Поиск
Список
Период
Сортировка
От Peter Geoghegan
Тема Re: Solaris testers wanted for strxfrm() behavior
Дата
Msg-id CAM3SWZRKGi3PcpcUtQ05uRsKAB72GaM86B4zr4DrJzoin83bMw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Solaris testers wanted for strxfrm() behavior  (Peter Geoghegan <pg@heroku.com>)
Список pgsql-hackers
On Sun, Jun 28, 2015 at 4:35 PM, Peter Geoghegan <pg@heroku.com> wrote:
> It hardly matters much, but I don't think that it is. I think the
> issue is entirely explained by sloppy code in the Solaris 8 stdlib.

I don't imagine that it will come as a surprise to anybody, but the
manpage [1] for strxfrm() covering old Solaris libc versions
(predating even version 8) states:

"No more than n bytes are placed into the resulting array pointed to
by s1, including the terminating null byte" ('n' is the bufsize
argument passed by the caller).

This is proof positive (though it is hardly needed) that Solaris was
never supposed to allow this. I also noticed that the manpage had a
typo:

"Because no return value is reserved to indicate an error, an
application wishing to check for error situations should set errno to
0, then call strcoll(3C), then check errno and if it is non-zero,
assume an error has occurred."

Obviously this is a copy-paste leftover from the strcoll() manpage.
Pretty slipshod for a C standard library implementation, I would say.

[1] http://docs.oracle.com/cd/E19455-01/806-0627/6j9vhfn88/index.html#indexterm-1090
-- 
Peter Geoghegan



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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: anole: assorted stability problems
Следующее
От: Robert Haas
Дата:
Сообщение: Re: drop/truncate table sucks for large values of shared buffers