On 21 June 2011 23:51, Tom Lane <t...@sss.pgh.pa.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
