Re: pgindent versus struct members and typedefs

Поиск
Список
Период
Сортировка
От Chao Li
Тема Re: pgindent versus struct members and typedefs
Дата
Msg-id 347EA055-D626-414C-B10D-7E70041B9B55@gmail.com
обсуждение исходный текст
Ответ на pgindent versus struct members and typedefs  (Nathan Bossart <nathandbossart@gmail.com>)
Ответы Re: pgindent versus struct members and typedefs
Список pgsql-hackers

> On Dec 3, 2025, at 06:00, Nathan Bossart <nathandbossart@gmail.com> 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
statementwithout 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/







В списке pgsql-hackers по дате отправления: