[PATCH] pgindent truncates last line of files missing a trailing newline

On 2026-02-16 Mo 9:09 AM, Akshay Joshi wrote:

Hi Hackers,

I have encountered a bug in "*src/tools/pg_bsd_indent/lexi.c"* where
pgindent was incorrectly dropping the final line of a file if that
line did not end with a newline character (\n). This occurred because
the EOF logic triggered a termination of the processing loop before
the remaining buffer was flushed to the output.

*Steps to Reproduce:*

1. Create a *header/c* file with some content but no newline at the
very end.
2. Run pgindent on those files.
3. Check the file content. The file is now empty or missing the last
line.

This patch ensures that had_eof states do not bypass the final buffer
processing, preserving the integrity of the source code regardless of
trailing whitespace.

Yeah. I wonder if we shouldn't be just ensuring that there is a line
feed at the end of the buffer, i.e. add one if it's not there. We
shouldn't be adding files without a trailing LF, and ensuring there is
one seems like a reasonable thing to do in pg_bsd_indent.

cheers

andrew

--
Andrew Dunstan
EDB:https://www.enterprisedb.com

Andrew Dunstan <andrew@dunslane.net> writes:

Yeah. I wonder if we shouldn't be just ensuring that there is a line
feed at the end of the buffer, i.e. add one if it's not there. We
shouldn't be adding files without a trailing LF, and ensuring there is
one seems like a reasonable thing to do in pg_bsd_indent.

+1

regards, tom lane

On Mon, Feb 16, 2026 at 10:20 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:

Andrew Dunstan <andrew@dunslane.net> writes:

Yeah. I wonder if we shouldn't be just ensuring that there is a line
feed at the end of the buffer, i.e. add one if it's not there. We
shouldn't be adding files without a trailing LF, and ensuring there is
one seems like a reasonable thing to do in pg_bsd_indent.

+1

+1. That will allow me to remove some code from my patch preparation
script. Ref. [1]/messages/by-id/CAExHW5v8u7-2H2LqWP3ybhh5GnAVVeCOYuTfkg9pmdnrLwAtNA@mail.gmail.com

[1]: /messages/by-id/CAExHW5v8u7-2H2LqWP3ybhh5GnAVVeCOYuTfkg9pmdnrLwAtNA@mail.gmail.com

--
Best Wishes,
Ashutosh Bapat

I have addressed the review comments from Andrew.
Attached is the v2 patch, ready for review.

On Tue, Feb 17, 2026 at 7:50 AM Ashutosh Bapat
<ashutosh.bapat.oss@gmail.com> wrote:

Akshay Joshi <akshay.joshi@enterprisedb.com> writes:

I have addressed the review comments from Andrew.
Attached is the v2 patch, ready for review.

I'm not sure I want to expend the brain cells to figure out whether
this is a correct/complete patch. If pg_bsd_indent were less of an
undercommented spaghetti-code nightmare, maybe fixing it here would
be reasonable. But as things stand, why don't we just fix this in
the perl wrapper, as attached?

(In any case, I'm not in favor of adding a test case, because that
would require putting a trailing-newline-less .c file into our tree.
At best there would be a permanent hazard of something "fixing"
the file.)

regards, tom lane

On 2026-03-26 Th 12:29 PM, Tom Lane wrote:

Akshay Joshi<akshay.joshi@enterprisedb.com> writes:

I have addressed the review comments from Andrew.
Attached is the v2 patch, ready for review.

I'm not sure I want to expend the brain cells to figure out whether
this is a correct/complete patch. If pg_bsd_indent were less of an
undercommented spaghetti-code nightmare, maybe fixing it here would
be reasonable. But as things stand, why don't we just fix this in
the perl wrapper, as attached?

Well, I thought we were trying to reduce the fixups we did in pgindent.
However, I take your point about the ugly nature of the pg_bsd_indent
code. So I'm ok with this fix, which is quite straightforward.

(In any case, I'm not in favor of adding a test case, because that
would require putting a trailing-newline-less .c file into our tree.
At best there would be a permanent hazard of something "fixing"
the file.)

fair point.

cheers

andrew

--
Andrew Dunstan
EDB:https://www.enterprisedb.com

Andrew Dunstan <andrew@dunslane.net> writes:

On 2026-03-26 Th 12:29 PM, Tom Lane wrote:

I'm not sure I want to expend the brain cells to figure out whether
this is a correct/complete patch. If pg_bsd_indent were less of an
undercommented spaghetti-code nightmare, maybe fixing it here would
be reasonable. But as things stand, why don't we just fix this in
the perl wrapper, as attached?

Well, I thought we were trying to reduce the fixups we did in pgindent.

Yeah, other things being equal I too would prefer to fix it within
pg_bsd_indent. But other things are not equal: the complexity
and reviewability of the proposed v2 patch are not comparable to
a one-liner fix in the wrapper.

However, I take your point about the ugly nature of the pg_bsd_indent
code. So I'm ok with this fix, which is quite straightforward.

I'll make it so.

regards, tom lane

On Fri, Mar 27, 2026 at 03:28:16PM -0400, Tom Lane wrote:

Andrew Dunstan <andrew@dunslane.net> writes:

On 2026-03-26 Th 12:29 PM, Tom Lane wrote:

I'm not sure I want to expend the brain cells to figure out whether
this is a correct/complete patch. If pg_bsd_indent were less of an
undercommented spaghetti-code nightmare, maybe fixing it here would
be reasonable. But as things stand, why don't we just fix this in
the perl wrapper, as attached?

Well, I thought we were trying to reduce the fixups we did in pgindent.

Yeah, other things being equal I too would prefer to fix it within
pg_bsd_indent. But other things are not equal: the complexity
and reviewability of the proposed v2 patch are not comparable to
a one-liner fix in the wrapper.

I think the only way forward if we want to continue modifying
pg_bsd_indent is to rename most of the variables and add some sanity to
the code.

--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com

Do not let urgent matters crowd out time for investment in the future.