On 22.06.2011 01:51, Tom Lane wrote:
I notice that the SSI code is rather heavily invested in function
declarations like this:
extern bool PageIsPredicateLocked(const Relation relation, const BlockNumber
blkno);
I find this to be poor style, and would like to see if there's any
support for getting rid of the "const" keywords. My objections are
twofold:
1. What such a "const" marking actually does is to forbid the function
from changing the value of its local variable that received the passed
parameter value. While you may or may not think that it's good style
to avoid doing so, whether the function chooses to do that or not is
surely no business of its callers'. Putting such a marking into the
extern declaration doesn't create any useful API contract, it just means
you'll have to change the declaration if you change the function's
implementation.
Yeah, that makes no sense.
2. In cases such as "const Relation foo" where the parameter type is
a typedeffed pointer, it is easy for readers to arrive at the false
conclusion that this guarantees the function doesn't change the
pointed-to structure. But it guarantees no such thing, because that
construction is *not* equivalent to "const struct RelationData *foo";
rather it means "struct RelationData * const foo", ie only the pointer
is being const-ified, not that to which it points. The function can
hack the struct contents, or pass the pointer to functions that do
arbitrary things, and the compiler won't make a whimper. So I think
that declarations like this are positively pernicious --- they'll
mislead all but the most language-lawyerly readers.
Agreed. I did not realize the difference in the SSI patch. The intention
of the const declarations was clearly to document that the function
doesn't modify the data the pointer points to, but if the const
qualifier doesn't accomplish that, it's just wrong.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
