On ons, 2011-11-09 at 21:15 +, Thomas Munro wrote:
> I've attached a new patch, which simply adds the keyword 'const' in
> lots of places, no new functions etc. This version generates no
> warnings under -Wcast-qual (now that I've read Peter E's thread and
> been inspired to fix up some places
Bruce Momjian wrote:
>> No, version 2 of the patch used the strchr() technique and has
>> *zero* new functions and *zero* new macros.
>
> Right. I was referring to the non-strchr() approach in the
> initial patch.
I'm sorry that I misunderstood you.
So, I don't think I've heard any argumen
Kevin Grittner wrote:
> Bruce Momjian wrote:
>
> > I realize the patch only added 1-2 new const functions
>
> No, version 2 of the patch used the strchr() technique and has
> *zero* new functions and *zero* new macros.
Right. I was referring to the non-strchr() approach in the initial
patch.
Bruce Momjian wrote:
> I realize the patch only added 1-2 new const functions
No, version 2 of the patch used the strchr() technique and has
*zero* new functions and *zero* new macros.
> but this is only a small area of the code being patched --- a full
> solution would have many more comple
Kevin Grittner wrote:
> Tom Lane 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 d
Tom Lane 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 o
"Kevin Grittner" writes:
> Tom mentioned the strchr() function, which does do that. I don't
> actually find that surprising given my understanding of the
> semantics. That means that the function is promising not to modify
> the character array, but is not asserting that it knows the
> character
Peter Eisentraut writes:
> On ons, 2011-11-09 at 10:49 -0500, Tom Lane wrote:
>> Now admittedly you can hack it, in the same
>> spirit as the C library functions that are declared to take const
>> pointers and return non-const pointers to the very same data
> Which C library functions do that?
Peter Eisentraut wrote:
> On ons, 2011-11-09 at 10:49 -0500, Tom Lane wrote:
>> Now admittedly you can hack it, in the same
>> spirit as the C library functions that are declared to take const
>> pointers and return non-const pointers to the very same data
>
> Which C library functions do that?
On ons, 2011-11-09 at 10:49 -0500, Tom Lane wrote:
> Now admittedly you can hack it, in the same
> spirit as the C library functions that are declared to take const
> pointers and return non-const pointers to the very same data
Which C library functions do that?
--
Sent via pgsql-hackers maili
Florian Pflug wrote:
> On Nov9, 2011, at 22:54 , Kevin Grittner wrote:
>> Tom Lane wrote:
>>
>>> I don't doubt that just duplicating macros and inlineable
>>> functions is a wash performance-wise (in fact, in principle it
>>> shouldn't change the generated code at all).
>>
>> I had the impressi
Tom Lane wrote:
> In general I don't have an objection to adding "const" to
> individual routines, so long as it doesn't create propagating
> requirements to const-ify other code. This may be the only way to
> do it.
As I understand it (although I'm no C expert), a "const" qualifier
on a func
"Kevin Grittner" writes:
> Thomas Munro wrote:
>> There is another option: if list_head is changed to take a pointer
>> to const List and return a pointer to non-const ListCell
>> (something I was trying to avoid before), then no XXX_const
>> functions/macros are necessary, and all of the functio
Florian Pflug writes:
> If we're concerned about helping the compiler produce better code,
> I think we should try to make our code safe under strict aliasing
> rules. AFAIK, that generally helps much more than const-correctness.
> (Dunno how feasible that is, though)
The last time we talked abou
On Nov9, 2011, at 22:54 , Kevin Grittner wrote:
> Tom Lane wrote:
>
>> I don't doubt that just duplicating macros and inlineable
>> functions is a wash performance-wise (in fact, in principle it
>> shouldn't change the generated code at all).
>
> I had the impression that compilers these days co
Thomas Munro wrote:
> There is another option: if list_head is changed to take a pointer
> to const List and return a pointer to non-const ListCell
> (something I was trying to avoid before), then no XXX_const
> functions/macros are necessary, and all of the functions from the
> first patch can
On Nov9, 2011, at 22:38 , Tom Lane wrote:
> I think that "const" works materially better in C++ where you can
> overload foo(struct *) and foo(const struct *) and let the compiler sort
> out which is being called. In C, the impedance match is a lot worse,
> so you have to pick and choose where con
"Kevin Grittner" writes:
>> In C, the impedance match is a lot worse, so you have to pick and
>> choose where const is worth the trouble.
>
> Agreed. And I'm not sure how much of what Thomas is proposing is
> worth it; it just seems prudent to consider it while the offer is
> being made to do t
Tom Lane wrote:
> I don't doubt that just duplicating macros and inlineable
> functions is a wash performance-wise (in fact, in principle it
> shouldn't change the generated code at all).
I had the impression that compilers these days could sometimes
better optimize across calls to functions w
"Kevin Grittner" writes:
> If people aren't inclined to support this on the grounds of API
> clarity, maybe we should do some sort of benchmark run while we have
> a patch which applies cleanly before writing off the possible
> performance impact, but I'm not sure what makes a good stress-test
> f
Robert Haas wrote:
> So what happens when someone wants to use list_nth in one of the
> outfuncs? Would we then rip all these back out?
If we just go this far and don't create a separate const flavor of
the one function and two macros, then we would at least need to rip
out the const keyword
On Wed, Nov 9, 2011 at 2:35 PM, Kevin Grittner
wrote:
> Robert Haas wrote:
>
>> If it doesn't uglify the code, there aren't any negatives. I'm
>> just saying we may not be able to get very far before we run up
>> against that issue. For example, in the OP, Thomas wrote:
>>
>> 7. I made a list_
On 9 Nov 2011, at 15:33, Peter Geoghegan wrote:
> On 9 November 2011 15:24, Tom Lane wrote:.
>> If you go down this road you soon start needing duplicate functions
>> for no other reason than that one takes/returns "const" and one doesn't.
>
> Why would you have to do that?
>
> To my mind, the
On Wed, Nov 9, 2011 at 11:28 AM, Kevin Grittner
wrote:
>> The kicker is that it's a lot of work for an unbelievably tiny
>> benefit, sometimes a negative benefit.
>
> Assuming duplicate declarations with and without const are off the
> table, where do you see the negative?
If it doesn't uglify th
Robert Haas wrote:
> My feeling is that there's no harm (and possibly some benefit) in
> const-ifying functions that do very simple things. But as soon as
> you get to functions where the const-ness starts growing all over
> the system like kudzu, it's time to run away screaming.
The patch at
On 9 November 2011 15:24, Tom Lane wrote:.
> If you go down this road you soon start needing duplicate functions
> for no other reason than that one takes/returns "const" and one doesn't.
Why would you have to do that?
To my mind, the fact that const "spreads" is a feature, not a deficiency.
-
On Wed, Nov 9, 2011 at 10:45 AM, Kevin Grittner
wrote:
> Tom Lane wrote:
>>> Perhaps there should be a few more 'XXX_const' accessor function
>>> variants, for example list_nth_const,
>>
>> This is exactly what was bothering Robert and me about Peter's
>> patch.If you go down this road you soon
"Kevin Grittner" writes:
> Tom Lane wrote:
>> This is exactly what was bothering Robert and me about Peter's
>> patch.If you go down this road you soon start needing duplicate
>> functions for no other reason than that one takes/returns "const"
>> and one doesn't.
> What about existing function
Peter Geoghegan writes:
> On 9 November 2011 15:24, Tom Lane wrote:.
>> If you go down this road you soon start needing duplicate functions
>> for no other reason than that one takes/returns "const" and one doesn't.
> Why would you have to do that?
list_nth is an example. Now admittedly you ca
Tom Lane wrote:
>> Perhaps there should be a few more 'XXX_const' accessor function
>> variants, for example list_nth_const,
>
> This is exactly what was bothering Robert and me about Peter's
> patch.If you go down this road you soon start needing duplicate
> functions for no other reason than t
Thomas Munro writes:
> I am a long time user and fan of PostgreSQL and have built various
> projects large and small on every major release since 6.5. Recently
> I decided to try doing something more with the source than just
> compiling it, and spent some time 'constifying' some parts of the cod
31 matches
Mail list logo
