Re: Nitpicking: unnecessary NULL-pointer check in pg_upgrade's controldata.c
От | Tom Lane |
---|---|
Тема | Re: Nitpicking: unnecessary NULL-pointer check in pg_upgrade's controldata.c |
Дата | |
Msg-id | 25808.1435330471@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Nitpicking: unnecessary NULL-pointer check in pg_upgrade's controldata.c (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Nitpicking: unnecessary NULL-pointer check in
pg_upgrade's controldata.c
|
Список | pgsql-hackers |
Robert Haas <robertmhaas@gmail.com> writes: > On Fri, Jun 26, 2015 at 10:21 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> I agree that the correct handling of this particular case is to mark it >> as not-a-bug. We have better things to do. > Well, I find that a disappointing conclusion, but I'm not going to > spend a lot of time arguing against both of you. But, for what it's > worth: it's not as if somebody is going to modify the code in that > function to make output == NULL a plausible option, so I think the > change could easily be justified on code clean-up grounds if nothing > else. There's not much point calling fgets on a FILE unconditionally > and then immediately thereafter allowing for the possibility that > output might be NULL. That's not easing the work of anyone who might > want to modify that code in the future; it just makes the code more > confusing. Well, if you find this to be good code cleanup on its own merits, you have a commit bit, you can go commit it. I'm just saying that Coverity is not a good judge of code readability and even less of a judge of likely future changes. So we should not let it determine whether we approve of "unnecessary" tests. regards, tom lane
В списке pgsql-hackers по дате отправления: