public inbox for [email protected]  

help / color / mirror / Atom feed

From: Chao Li <[email protected]>
To: Nathan Bossart <[email protected]>
Cc: Rahila Syed <[email protected]>
Cc: Robert Haas <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Subject: Re: pgindent versus struct members and typedefs
Date: Wed, 3 Dec 2025 06:46:33 +0800
Message-ID: <[email protected]> (raw)
In-Reply-To: <aS9hkwnkWf3dZIA_@nathan>
References: <aS9hkwnkWf3dZIA_@nathan>



> On Dec 3, 2025, at 06:00, Nathan Bossart <[email protected]> wrote:
> 
> On Mon, Dec 01, 2025 at 05:04:23PM -0600, Nathan Bossart wrote:
>> On Tue, Dec 02, 2025 at 05:35:34AM +0800, Chao Li wrote:
>>> ```
>>> + else if (entry->type == DSMR_ENTRY_TYPE_DSH &&
>>> + entry->dsh.dsa_handle !=DSA_HANDLE_INVALID)
>>> ```
>>> 
>>> Missing a white space after !=.
>> 
>> I agree, but for some reason, pgindent insists on removing that space.  I'm
>> leaving that for another thread.
> 
> So, this seems to have something to do with the struct member having the
> same name as a typedef.  If I rename the member, pgindent adds the space as
> expected.  Interestingly, changing the != to a == also fixes the spacing.
> There are a couple of other examples in the code:
> 
> src/backend/storage/ipc/dsm_registry.c: entry->dsh.dsa_handle !=DSA_HANDLE_INVALID)
> src/backend/replication/logical/logicalfuncs.c: ctx->options.output_type !=OUTPUT_PLUGIN_TEXTUAL_OUTPUT)
> src/bin/pg_basebackup/pg_basebackup.c: if (state.manifest_file !=NULL)
> src/bin/pg_basebackup/pg_basebackup.c: state->manifest_file !=NULL)
> src/bin/pg_basebackup/pg_basebackup.c: else if (state->manifest_file !=NULL)
> 
> I used the following command to find these:
> 
> grep -E "!=[A-Za-z]" ./* -rI
> 
> AFAICT this is a special case of the note added to pgindent's README by
> commit c4133ec:
> 
> pgindent will mangle both declaration and definition of a C function whose
> name matches a typedef.  Currently the best workaround is to choose
> non-conflicting names.
> 
> I tried to fix pgindent for a few, but the code is basically impenetrable.
> I didn't find any fixes upstream [0], either.  As noted above, we could
> also fix it by avoiding the naming conflicts.  However, I can't imagine
> that's worth the churn, and I've already spent way too much time on this,
> so IMHO the best thing to do here is nothing.
> 

I think that’s fine.

Actually I see the other problem with pgindent, where if a “else” clause contains a multiple-line comment and a single statement without braces, for example:

```
else
     /*
      * comment
      */
     printf(…);
```

Then pgindent will blindly add an empty line after “else”, so we get:
```
else

     /*
      * comment
      */
     printf(…);

```

I tried to fix but failed. For that problem, a solution is to add braces to the “else” clause.

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/

view thread (22+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: pgindent versus struct members and typedefs
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox