Обсуждение: [PATCH] pgindent truncates last line of files missing a trailing newline

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]

[1]
https://www.postgresql.org/message-id/flat/CAExHW5v8u7-2H2LqWP3ybhh5GnAVVeCOYuTfkg9pmdnrLwAtNA%40mail.gmail.com#fdbb87e825f89e7109dfb0ed959b2dd4

--
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:
>
> 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]
>
> [1]
https://www.postgresql.org/message-id/flat/CAExHW5v8u7-2H2LqWP3ybhh5GnAVVeCOYuTfkg9pmdnrLwAtNA%40mail.gmail.com#fdbb87e825f89e7109dfb0ed959b2dd4
>
> --
> Best Wishes,
> Ashutosh Bapat

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

diff --git a/src/tools/pgindent/pgindent b/src/tools/pgindent/pgindent
index 7481696a584..1081b28db8f 100755
--- a/src/tools/pgindent/pgindent
+++ b/src/tools/pgindent/pgindent
@@ -224,6 +224,9 @@ sub pre_indent
 {
     my $source = shift;
 
+    ## Ensure file ends with a newline (pg_bsd_indent messes up otherwise)
+    $source .= "\n" unless substr($source, -1) eq "\n";
+
     ## Comments
 
     # Convert // comments to /* */

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.