Em ter., 13 de jul. de 2021 às 11:29, Tom Lane <t...@sss.pgh.pa.us> escreveu:
> Laurenz Albe <laurenz.a...@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?", but it's ok. regards, Ranier Vilela
