Re: Are we missing (void) when return value of fsm_set_and_search is ignored?
От | Julien Rouhaud |
---|---|
Тема | Re: Are we missing (void) when return value of fsm_set_and_search is ignored? |
Дата | |
Msg-id | 20210604042805.d7xsdhmsbwsxczwi@nol обсуждение исходный текст |
Ответ на | Re: Are we missing (void) when return value of fsm_set_and_search is ignored? (Peter Eisentraut <peter.eisentraut@enterprisedb.com>) |
Ответы |
Re: Are we missing (void) when return value of fsm_set_and_search is ignored?
Re: Are we missing (void) when return value of fsm_set_and_search is ignored? |
Список | pgsql-hackers |
On Thu, Jun 03, 2021 at 02:57:42PM +0200, Peter Eisentraut wrote: > On 03.06.21 12:54, Bharath Rupireddy wrote: > > It looks like for some of the fsm_set_and_search calls whose return > > value is ignored (in fsm_search and RecordPageWithFreeSpace), there's > > no (void). Is it intentional? In the code base, we generally have > > (void) when non-void return value of a function is ignored. > > I don't think that is correct. I don't see anyone writing > > (void) printf(...); We somehow do have a (void) fprint(...) in src/port/getopt.c. > so this is not a generally applicable strategy. > > We have pg_nodiscard for functions where you explicitly want callers to > check the return value. In all other cases, callers are free to ignore > return values. Yes, but we have a lot a examples of functions without pg_nodiscard and callers still explicitly ignoring the results, like fsm_vacuum_page() in the same file. It would be more consistent and make the code slightly more self explanatory.
В списке pgsql-hackers по дате отправления: