Re: const correctness

Поиск
Список
Период
Сортировка
От Kevin Grittner
Тема Re: const correctness
Дата
Msg-id 4EBAAA9D0200002500042C4B@gw.wicourts.gov
обсуждение исходный текст
Ответ на Re: const correctness  (Thomas Munro <munro@ip9.org>)
Ответы Re: const correctness  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Thomas Munro <munro@ip9.org> wrote:
> There is another option: if list_head is changed to take a pointer
> to const List and return a pointer to non-const ListCell
> (something I was trying to avoid before), then no XXX_const
> functions/macros are necessary, and all of the functions from the
> first patch can keep their 'const', adding const to 930 lines.
Now that you mention it, I think that's better anyway.  Just because
you don't want the *called* function to change something doesn't
seem like it should imply anything about whether the *caller* should
be able to change something.  Leave that to the caller unless the
function is quite sure that it is returning a pointer to something
which should be immutable in all cases.
> I've attached a new patch, which simply adds the keyword 'const'
> in lots of places, no new functions etc.  This version generates
> no warnings under -Wcast-qual (now that I've read Peter E's thread
> and been inspired to fix up some places that previously cast away
> const) for all code under backend/nodes.  To achieve that I had to
> stray outside backend/nodes and change get_leftop and get_rightop
> (from clauses.h).
On this end it applies cleanly, compiles without warning, and passes
check-world regression tests.
-Kevin


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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Disable OpenSSL compression
Следующее
От: Florian Pflug
Дата:
Сообщение: Re: const correctness