Re: GinPageIs* don't actually return a boolean

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: GinPageIs* don't actually return a boolean
Дата
Msg-id 20160211181516.55qduxd6irxmvx7v@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: GinPageIs* don't actually return a boolean  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: GinPageIs* don't actually return a boolean  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On 2016-02-11 13:06:14 -0500, Tom Lane wrote:
> But I'm unconvinced that we need to make our .c files prepared for
> stdbool.h to be #included in them.

The fixes, besides two stylistic edits around !! use, are all in
headers. The issue is that we return things meant to be used in a
boolean context, that's not just 0/1 but some random set bit.  Looking
over the (outdated) patch attached to
http://archives.postgresql.org/message-id/20150812161140.GD25424%40awork2.anarazel.de
it's not completely outlandish that one wants to use one of these
functions, but also something that uses stdbool.h.

> By that argument, any random
> symbol in any system header in any platform on the planet is a hazard
> to us.

Don't think that's really the same. C99's booleans are part of the
standard, and have surprising behaviour that you can't get on the C
level (they always contain 1/0 after assignment). That makes for more
likely and more subtle bugs.

And anyway, these macros are a potential issue even without stdbool.h
style booleans. If you compare them using equality, you can get into
trouble...

Andres



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: [PATCH v4] GSSAPI encryption support
Следующее
От: Andres Freund
Дата:
Сообщение: Re: Performance degradation in commit ac1d794