Re: Coding style point: "const" in function parameter declarations

On 21 June 2011 23:51, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 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.

People may be confused by that inconsistency though. I agree that it
generally doesn't make sense to const-qualify a passed-by-value
parameter. I've seen it done, but I struggle to recall a case where I
thought that it made much 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.

IMHO, you don't have to be that much of a language lawyer to pick up
on that, because it's not as if the typedef has very effectively
encapsulated the fact that the underlying type is actually a pointer
anyway. I for one find it intuitively obvious that the pointed-to data
isn't declared const in your example.

> Declarations like "const structtype *param" are fine, because those
> create a real, enforced contract on what the function can do to data
> that is visible to its caller.  But I don't see any value at all in
> const-ifying the parameter itself.

+1

const is actually an example of C++ influencing C. It tends to work
very well with C++, where it cascades usefully throughout an entire
system, and where a distinction can be made between logical and
bit-wise const-ness. In C, it is a bit wishy-washy, particularly the
fact that what happens when const-ness is violated is undefined,
rather than just having the code fail to compile. const is also
supposed to be able to facilitate certain compiler optimisations,
which is why you have the undefined behaviour thing (what if the
variable is stored in read-only memory?), but that isn't very relevant
in practice.

--
Peter Geoghegan       http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services