Re: printf %s with NULL pointer (was Re: BUG #17098: Assert failed on composing an error message when adding a type to an extension being dropped)
От | Ranier Vilela |
---|---|
Тема | Re: printf %s with NULL pointer (was Re: BUG #17098: Assert failed on composing an error message when adding a type to an extension being dropped) |
Дата | |
Msg-id | CAEudQAq22dUhHp9ryKNOnro0HkQWiJE1F3g3VxHUFsqQ4ZkyeA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: printf %s with NULL pointer (was Re: BUG #17098: Assert failed on composing an error message when adding a type to an extension being dropped) (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: printf %s with NULL pointer (was Re: BUG #17098: Assert failed on composing an error message when adding a type to an extension being dropped)
|
Список | pgsql-hackers |
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?",
but it's ok.
regards,
Ranier Vilela
В списке pgsql-hackers по дате отправления: