Re: const correctness - Mailing list pgsql-hackers

From Kevin Grittner
Subject Re: const correctness
Date
Msg-id 4EBAAA9D0200002500042C4B@gw.wicourts.gov
Whole thread Raw
In response to Re: const correctness  (Thomas Munro <munro@ip9.org>)
Responses Re: const correctness
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: Disable OpenSSL compression
Next
From: Florian Pflug
Date:
Subject: Re: const correctness