Re: Solaris testers wanted for strxfrm() behavior - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: Solaris testers wanted for strxfrm() behavior
Date
Msg-id CAM3SWZRKGi3PcpcUtQ05uRsKAB72GaM86B4zr4DrJzoin83bMw@mail.gmail.com
Whole thread Raw
In response to Re: Solaris testers wanted for strxfrm() behavior  (Peter Geoghegan <pg@heroku.com>)
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: anole: assorted stability problems
Next
From: Robert Haas
Date:
Subject: Re: drop/truncate table sucks for large values of shared buffers