Re: Solaris testers wanted for strxfrm() behavior

On Sat, Jun 27, 2015 at 11:57:30AM -0700, Peter Geoghegan wrote:
> On Sat, Jun 27, 2015 at 9:51 AM, Noah Misch <noah(at)leadboat(dot)com> wrote:
> > PostgreSQL 9.5 adds a strxfrm() call in bttext_abbrev_convert(), which does
> > not account for the Solaris bug. I wish to determine whether that bug is
> > still relevant today. If you have access to Solaris with the is_IS.ISO8859-1
> > locale installed (or root access to install it), please compile and run the
> > attached test program on each Solaris version you have available. Reply here
> > with the program's output. I especially need a report from Solaris 10, but
> > reports from older and newer versions are valuable. Thanks.
>
> I did consider this.
>
> Sorry, but I must question the point of worrying about an ancient bug
> in Solaris.

One function had a comment explaining its workaround for an OS bug, while
another function ignored the same bug. That is always a defect in the
comments at least; our code shall tell a uniform story about its API
assumptions. I started this thread estimating that it would end with me
merely deleting the comment. Thomas Munro and Tom Lane located evidence I
hadn't found, evidence that changed the conclusion.

> When you have to worry about a standard library function
> blithely writing past the end of a buffer, when its C89 era interface
> must be passed the size of said buffer, where does it end?

Don't worry about the possibility of such basic bugs until someone reports
one. Once you have such a report, though, assume the interface behaves as
last reported until you receive new evidence. We decide whether to work
around such bugs based on factors like prevalence of affected systems,
simplicity of the workaround, and ease of field diagnosis in the absence of
the workaround. Non-factors include whether the bug is egregious, is contrary
to documentation, or is contrary to a pertinent third-party specification.
Those sources speak to which of the library provider or PostgreSQL was wrong,
but they play little or no role in dictating the workarounds to deploy.

I hope that clarifies things.

nm