On Sat, Jun 27, 2015 at 7:14 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I think the point of Noah's query is to find out whether "ancient" is an
> accurate description. If indeed nothing newer than Solaris 8 exhibits
> the bug, I'd be okay with not working around it, but otherwise we have
> some decisions to make.
Even Solaris 9 is EOL.
> Also, the post Noah dug up was merely the oldest description of the
> problem. I believe what prompted us to actually change the code was
> some reports in July 2003:
>
> http://www.postgresql.org/message-id/flat/56510AAEF435D240958D1CE8C6B1770A016D2DB9@mailc03.aurigin.com
You said it yourself at the time -- why trust the strxfrm()
implementation when a NULL pointer is passed? It may have worked on
someone's machine in 2003, but that isn't a very good reason. It was
never a documented part of the interface that this fails or that
works; how could it be? This Solaris strxfrm() issue is (in the
simplest and least contentious sense) a bug. It is not a portability
issue. Someone made a mistake, and most likely the mistake was
corrected in the next point release. That is the only logical
explanation I can see.
I wouldn't say that adding defenses to workaround serious bugs in a C
stdlib is something we should never do, but ISTM that the standard for
undertaking that ought to be very high. BTW, unlike the author of
convert_string_datum(), I think it's okay that glibc sometimes returns
different values with strxfrm() calls on the same string (based on
whether or not the passed-in buffer is actually big enough to store
the transformed string) -- that is actually allowed by the standard, I
think. In other words, Solaris 8 has the only actually buggy strxfrm()
of the cases convert_string_datum() enumerates, since AFAICT the
standard doesn't promise that the strxfrm() return value need be
exact, only sufficient (this leeway seems useful to me).
--
Peter Geoghegan
