On Sat, Jun 27, 2015 at 7:14 PM, Tom Lane <t...@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/56510aaef435d240958d1ce8c6b1770a016d2...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
