Re: const correctness

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Geoghegan <peter(at)2ndquadrant(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Thomas Munro <munro(at)ip9(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: const correctness
Date: 2011-11-10 21:10:48
Message-ID: 201111102110.pAALAmT26396@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Kevin Grittner wrote:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> > The problem with it of course is that mistaken use could have the
> > effect of casting-away-const, which is exactly what we hoped to
> > prevent. Still, there may not be a better solution.
>
> Yeah, I've come to the conclusion that the compiler doesn't do the
> apparently-available optimizations using const precisely because it
> is so easy to cast away the property maliciously or accidentally.

Right. The compiler would have to look at the function code, and all
functions called by that function, to determine if const was honored ---
not something that is easily done.

I agree that the strchr() approach is best. I realize the patch only
added 1-2 new const functions, but this is only a small area of the code
being patched --- a full solution would have many more complex
duplicates, and awkward changes as we add features.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2011-11-10 21:15:34 Re: unaccent extension missing some accents
Previous Message Alvaro Herrera 2011-11-10 21:09:12 Re: foreign key locks, 2nd attempt