Re: cast result of copyNode()

From: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: cast result of copyNode()
Date: 2017-01-03 15:06:02
Message-ID: 5922d74e-2a24-10c2-61c2-9070519592ca@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 12/31/16 11:56 AM, Tom Lane wrote:
> But doesn't this result in a boatload of warnings on compilers that
> don't have typeof()?

> Also, if your answer is "you shouldn't get any warnings because
> copyObject is already declared to return void *", then why aren't
> we just relying on that today?

Currently, you don't get any warnings, and that would continue to be the
case if a compiler doesn't have typeof().

The casts that are currently there are (apparently) merely for style,
same as casting the result of malloc().

The problem this patch would address is that currently you can write

SomeNode *x = ...;

...

OtherNode *y = copyObject(x);

and there is no notice about that potential mistake.

This patch makes that an error.

If you are sure about what you are doing, you can add a cast. But
casting the result of copyObject() should be limited to a few specific
cases where the result is assigned to a generic Node * or something like
that.

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Merlin Moncure 2017-01-03 15:23:48 Re: merging some features from plpgsql2 project
Previous Message Pavel Stehule 2017-01-03 14:59:30 Re: proposal: session server side variables