Re: [PATCH] patch: handle files with no final newline

I am proposing an alternative way to provide the same feature/fix

https://github.com/robang74/busybox/commit/f2cb7cb8348

It is a relatively untested change to busybox, thus it lives in
'patchfix' separate branch

The gnu patch and the busybox patch are working differently, and this
is fine because the two tools aren't the same and do not behave the
same way. Just notice that creating a forgery like 3.diff which
contains a no-newline pragma, the pragma is applied to the file
despite the hunk isn't working at the end of the file. Accepting this
behaviour in busybox is like saying: per each file you find a
no-newline, truncate the '\n' at the end of the file (if any). Which
can simplify the logic introduced by Ron.

roberto@x280[4]:~/tmp$ cat a.txt
first line
second line
roberto@x280[4]:~/tmp$ cat b.txt
first line
middle line
second line
roberto@x280[4]:~/tmp$ cat 3.diff
--- a.txt 2026-04-20 03:55:43.552161887 +0200
+++ b.txt 2026-04-20 03:56:08.616232538 +0200
@@ -1,2 +1,3 @@
 first line
+middle line
 second line
\ No newline at end of file
roberto@x280[4]:~/tmp$ busybox patch a.txt <3.diff
patching file a.txt
roberto@x280[4]:~/tmp$ cat a.txt
first line
middle line
second lineroberto@x280
roberto@x280[4]:~/tmp$ patch a.txt <3.diff
patching file a.txt
Hunk #1 succeeded at 1 with fuzz 1.
roberto@x280[4]:~/tmp$ cat a.txt
first line
middle line
second line
roberto@x280[4]:~/tmp$

Considering how the Ron's patch works, I am proposing an alternative
way to implement it:

patch: handle files with no final newline, alt. by file truncation

This patch is inspired by Ron's patch and shares with it a few lines
of code. The Ron's patch is a bugfix because busybox diff supports
no-newline but patch didn't and this would break the sha/md5sum check
even when the busybox diff/patch would be used for applying a change.
The Ron's patch peeks ahead and introduces an ungetc EOF potentially
fragile when busybox is compiled against libc (old) alternatives.
While this patch relies on the assumption of writing a file not a pipe
or a stream to implement the same feature with a smaller size
increase.

Why am I not using a bloat-o-meter? Because it is a nice tool that
provides fashionable information to add in the patch comments but it
isn't tell the whole story and the whole story is that the final size
of the busybox is the footprint that matters

+:git-shell:uchaosys:busybox> size busybox

Before

   text    data     bss     dec     hex filename
1157243   18160    2056 1177459 11f773 busybox

w/ Roberto's

   text    data     bss     dec     hex filename
1157375   18160    2056 1177591 11f7f7 busybox

w/ Ron's

   text    data     bss     dec     hex filename
1157388   18160    2056 1177604 11f804 busybox

Best regards, R-