Em ter., 13 de jul. de 2021 às 11:29, Tom Lane <tgl@sss.pgh.pa.us> escreveu:
Laurenz Albe <laurenz.albe@cybertec.at> writes: > On Mon, 2021-07-12 at 13:20 -0400, Tom Lane wrote: >> So my feeling about this is that switching snprintf.c's behavior >> would produce some net gain in robustness for v12 and up, while >> not making things any worse for the older branches. I still hold >> to the opinion that we've already flushed out all the cases of >> passing NULL that we're likely to find via ordinary testing.
> New cases could be introduced in the future and might remain undetected. > What about adding an Assert that gags on NULLs, but still printing them > as "(null)"? That would help find such problems in a debug build.
I think you're missing my main point, which is that it seems certain that there are corner cases that do this *now*. I'm proposing that we redefine this as not being a crash case, full stop.
I agree with Laurenz Albe, that on Debug builds, *printf with NULL, must crash.
On production builds, fine, printing (null).
This will put a little more pressure on support, "Hey what mean's (null) in my logs?",