Re: BUG #16176: NULL value returned by category_sql argument to crosstab() causes segmentation fault

Joe Conway <[email protected]> Mon, 23 Dec 2019 13:40:34 -0500
Newsgroups gmane.comp.db.postgresql.bugs
Message-ID <[email protected]>
On 12/21/19 10:08 AM, Tom Lane wrote:
> Joe Conway <[email protected]> writes:
>> It appears that in pg11 (and presumably prior) when snprintf() is called
>> it is resolved (here at least )to __GI___snprintf() which comes directly
>> from libc. On my desktop machine the system snprintf() deals with a null
>> pointer argument without crashing. I guess this is why the crash was
>> platform dependent.
> 
> Right, glibc's version of snprintf has produced "(nil)" or "(null)"
> or something like that for many years.  I'm not sure if that's true
> among the BSDen.  One place where the platform snprintf does *not*
> survive this case is Windows.
> 
>> In pg12 (and presumably master), it is resolved to our own port function
>> pg_snprintf(), which in turn works its way to dopr(), where strlen() is
>> called on a null pointer and "<boom>".
> 
> Right.  While it would only take a couple more lines of code to act like
> glibc does, we intentionally adopted the stricter definition because it
> seemed more likely to expose bugs.  Looks like it just did.
> 
>> From what I can see, even on pg11 and prior, having a null category
>> never did anything useful. And in the 16 years or so since this has been
>> around, no one in my memory ever asked for that functionality, so I am
>> inclined to refuse NULL category values unless someone wants to make a
>> good case otherwise.
> 
> WFM, but I've never used crosstab() much so I don't have a good feeling
> for significant use-cases.

Pushed that way to all supported branches.

If someone arrives with a compelling use-case, the changes would likely
not be something we would want to back patch, so we can address it
if/when that happens.

Joe
-- 
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development
signature.asc (application/pgp-signature, 833 B)
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEg14x9eymXoJyHrH+N/L3QzX32GUFAl4BCiIACgkQN/L3QzX3
2GUl5Q//dkuxuO9DLnA4iqhofk46Hwju5yRKAATZZpg5oKaQDG6XWpICVOhrR3nn
AI+ICWrA37ZB9/Xa6zL5ALtsUp2xsDAN+viyTglBdjWcFGW30p1Ew118bBaJeUOg
yrVeuI0ifAK+jY+RgSj7kJzCUQXRRWXlGn7BBqwiaAbRsPbBXp4BgRJIGXy1dKsc
i19bvCadcV58PW5ksOBnqNcKje3wyeFntrLB1y5CHp6C/VyG8ynfzKvHVjmUkhcM
52V2l+Qjqk+DcNgvSHujngolOA7AxrCg9cVClk0m6HclGZAxZKWD9livu6U1wXc6
urFlKn6wATKQQ4nTCdOCdFODh+xMyBiaziRpj7jBRVT6GAoD1myowwks0/b+J1c6
YGb8TigM4pO6E9kg5RSuTe6y9xRYQ+6ZuCBCCHDaekzLGsJXr2JTb/yebsekUxF4
MjXA7fiUHKe39W49E+Ch6FSn0Uc1B6t6314rdzxz7f3xP7bFS975tVunctsVWxSZ
oDI9NpD2XDhPIpl/whbu3w8ioxWj3JUliUfMvjztNtCp4IZv1sEZxaLaN45e8YvO
r8tJOilZ69tDRuS1LrorjlkRTTZXiGiJdJs75odH35Snbmpo4HMzrEkvjHg6APiO
XKt6+xCvWbpmME17Azbu2O/oUGOeEaTls8AKRnqODu9vVLBXykk=
=9X9u
-----END PGP SIGNATURE-----