Feedback-ID: ie0a040ee:Fastmail
Message-ID: <fbfe2471-a001-49a6-a15b-3cb33b63e16f@eisentraut.org>
Date: Wed, 24 Jul 2024 20:26:55 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: warning: dereferencing type-punned pointer
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Tatsuo Ishii <ishii@postgresql.org>, pgsql-hackers@postgresql.org
References: <20240724.155525.366150353176322967.ishii@postgresql.org>
 <1218071.1721829945@sss.pgh.pa.us>
 <1fe7031f-3a25-40c3-b244-530ea42fc133@eisentraut.org>
 <1254018.1721844589@sss.pgh.pa.us>
Content-Language: en-US
From: Peter Eisentraut <peter@eisentraut.org>
In-Reply-To: <1254018.1721844589@sss.pgh.pa.us>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://www.postgresql.org/message-id/fbfe2471-a001-49a6-a15b-3cb33b63e16f%40eisentraut.org>
Precedence: bulk

On 24.07.24 20:09, Tom Lane wrote:
> Peter Eisentraut<peter@eisentraut.org>  writes:
>> On 24.07.24 16:05, Tom Lane wrote:
>>> I'm not very thrilled with these changes.  It's not apparent why
>>> your compiler is warning about these usages of IsA and not any other
>>> ones,
>> I think one difference is that normally IsA is called on a Node * (since
>> you call IsA to decide what to cast it to), but in this case it's called
>> on a pointer that is already of type ErrorSaveContext *.
> Hmm.  But there are boatloads of places where we call IsA on a
> pointer of type Expr *, or sometimes other things.  Why aren't
> those triggering the same warning?

It must have to do with the fact that the escontext field in 
JsonExprState has the object inline, not as a pointer.  AIUI, with 
dynamically allocated objects you have more liberties about what type to 
interpret them as than with actually declared objects.

If you change the member to a pointer

-   ErrorSaveContext escontext;
+   ErrorSaveContext *escontext;
  } JsonExprState;

and make the required adjustments elsewhere in the code, the warning 
goes away.

This arrangement would also appear to be more consistent with other 
executor nodes (e.g., ExprState, ExprEvalStep), so it might be worth it 
for consistency in any case.