Thread: Re: Remove useless casts to (char *)

Peter Eisentraut <peter@eisentraut.org> writes:

> On 06.02.25 12:49, Dagfinn Ilmari Mannsåker wrote:
>> I have only skimmed the patches, but one hunk jumped out at me:
>> Peter Eisentraut <peter@eisentraut.org> writes:
>> 
>>> diff --git a/src/backend/libpq/pqcomm.c b/src/backend/libpq/pqcomm.c
>>> index 1bf27d93cfa..937a2b02a4f 100644
>>> --- a/src/backend/libpq/pqcomm.c
>>> +++ b/src/backend/libpq/pqcomm.c
>>> @@ -1368,7 +1368,7 @@ internal_flush_buffer(const char *buf, size_t *start, size_t *end)
>>>       {
>>>           int            r;
>>>   -        r = secure_write(MyProcPort, (char *) bufptr, bufend -
>>> bufptr);
>>> +        r = secure_write(MyProcPort, unconstify(char *, bufptr), bufend - bufptr);
>>>             if (r <= 0)
>>>           {
>> Insted of unconstify here, could we not make secure_write() (and
>> be_tls_write()) take the buffer pointer as const void *, like the
>> attached?
>
> Yeah, that makes sense.  I've committed that.

Thanks, and thanks for catching be_gssapi_write(), which I had missed
due to not having gssapi enabled in my test build.

>  Here is a new patch set rebased over that.

I had a more thorough read-through this time (as well as applying and
building it), and it does make the code a lot more readable.

I noticed you in some places added extra parens around remaining casts
with offset additions, e.g.

-        XLogRegisterData((char *) old_key_tuple->t_data + SizeofHeapTupleHeader,
+        XLogRegisterData(((char *) old_key_tuple->t_data) + SizeofHeapTupleHeader,
                          old_key_tuple->t_len - SizeofHeapTupleHeader);

But not in others:

-        memcpy((char *) tuple->t_data + SizeofHeapTupleHeader,
-               (char *) data,
-               datalen);
+        memcpy((char *) tuple->t_data + SizeofHeapTupleHeader, data, datalen);


I don't have a particularly strong opinion either way (maybe -0.2 on the
extra parens), but I mainly think we should keep it consistent, and not
change it gratuitously.

Greppig indicates to me that the paren-less version is more common:

$ git grep -P '\(\w+\s*\**\) [\w>-]+ \+ \w+' | wc -l
283
$ git grep -P '\(\(\w+\s*\**\) [\w>-]+\) \+ \w+' | wc -l
96

So I think we should leave them as they are.

- ilmari

I have committed the rest of this with the adjustments you suggested.


On 10.02.25 18:44, Dagfinn Ilmari Mannsåker wrote:
>>   Here is a new patch set rebased over that.
> 
> I had a more thorough read-through this time (as well as applying and
> building it), and it does make the code a lot more readable.
> 
> I noticed you in some places added extra parens around remaining casts
> with offset additions, e.g.
> 
> -        XLogRegisterData((char *) old_key_tuple->t_data + SizeofHeapTupleHeader,
> +        XLogRegisterData(((char *) old_key_tuple->t_data) + SizeofHeapTupleHeader,
>                            old_key_tuple->t_len - SizeofHeapTupleHeader);
> 
> But not in others:
> 
> -        memcpy((char *) tuple->t_data + SizeofHeapTupleHeader,
> -               (char *) data,
> -               datalen);
> +        memcpy((char *) tuple->t_data + SizeofHeapTupleHeader, data, datalen);
> 
> 
> I don't have a particularly strong opinion either way (maybe -0.2 on the
> extra parens), but I mainly think we should keep it consistent, and not
> change it gratuitously.
> 
> Greppig indicates to me that the paren-less version is more common:
> 
> $ git grep -P '\(\w+\s*\**\) [\w>-]+ \+ \w+' | wc -l
> 283
> $ git grep -P '\(\(\w+\s*\**\) [\w>-]+\) \+ \w+' | wc -l
> 96
> 
> So I think we should leave them as they are.
> 
> - ilmari
> 
> 

Peter Eisentraut писал(а) 2025-02-23 21:23:
> I have committed the rest of this with the adjustments you suggested.
> 
> 
> On 10.02.25 18:44, Dagfinn Ilmari Mannsåker wrote:
>>>   Here is a new patch set rebased over that.
Hi

I mentioned this patch in my message 
https://www.postgresql.org/message-id/f28f3b45ec84bf9dc99fe129023a2d6b%40postgrespro.ru
Starting from it queries with Parallel Seq Scan (probably with other 
parallel executor nodes)
hang under the debugger in Linux and MacOs.
-- 
Best regards,

Vladlen Popolitov.

On Wed, Mar 26, 2025 at 10:01:47PM +0700, Vladlen Popolitov wrote:
> I mentioned this patch in my message
https://www.postgresql.org/message-id/f28f3b45ec84bf9dc99fe129023a2d6b%40postgrespro.ru
> Starting from it queries with Parallel Seq Scan (probably with other
> parallel executor nodes)
> hang under the debugger in Linux and MacOs.

Uh.  How could a simple cast impact a parallel seqscan?  That seems
unrelated to me.
--
Michael

Michael Paquier писал(а) 2025-03-27 05:20:
> On Wed, Mar 26, 2025 at 10:01:47PM +0700, Vladlen Popolitov wrote:
>> I mentioned this patch in my message 
>> https://www.postgresql.org/message-id/f28f3b45ec84bf9dc99fe129023a2d6b%40postgrespro.ru
>> Starting from it queries with Parallel Seq Scan (probably with other
>> parallel executor nodes)
>> hang under the debugger in Linux and MacOs.
> 
> Uh.  How could a simple cast impact a parallel seqscan?  That seems
> unrelated to me.
> --
> Michael
Hi Michel,

  I changed the debugging extension in VScode and this issue disappeared.
I am sorry for disturbing and taking your time.

-- 
Best regards,

Vladlen Popolitov.