Re: [HACKERS] Adding some const keywords to external interfaces

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "D'Arcy" "J(dot)M(dot)" Cain <darcy(at)druid(dot)net>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] Adding some const keywords to external interfaces
Date: 1999-01-24 18:19:18
Message-ID: 7744.917201958@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"D'Arcy" "J.M." Cain <darcy(at)druid(dot)net> writes:
> Actually, all the changes should be internal to our own code. Functions
> that take const char pointers can still send non-const pointers. The
> errors would be generated if we changed the return value of the library
> functions, not the arguments.

True, adding const decorations to function arguments is fairly harmless
from the caller's point of view, but it also provides only a small
fraction of the error checking available with a fully const-ified
interface.

More to the point, the patch you submitted was *not* adding consts to
function arguments, it was adding consts to struct fields. That *can*
cause errors in calling code, if the caller happens to copy the value
of such a field into a local variable that's not declared const, pass
it as an argument to a function not marked const, etc.

I guess my question is "why start here?".

>> if we want to take const-safety seriously the effects will ripple
>> throughout the code...

> I would love to see const-safety given more attention but certainly
> we should make sure our external interfaces are correct so that people
> writing to them have the opportunity to do full error checking.

Well, that's exactly my point. I don't see much value in doing a
half-baked job of decorating the interface with const declarations;
you don't get much real error checking that way. If we are going to
take const-safety seriously then we need to do the whole job.

That's a fair amount of work that will impact outside applications as
well as a lot of our own code (certainly most of interfaces/ and bin/,
more if we start const-ifying the backend's internal interfaces).
I think we need a pgsql-hackers consensus and commitment to the idea
before we start doing it.

regards, tom lane

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 1999-01-24 18:31:05 Re: [HACKERS] Q about heap_getattr
Previous Message Vadim Mikheev 1999-01-24 18:09:13 Re: [HACKERS] Q about heap_getattr