Crash In the absence of the last empty line

[stabud]

Hi Ray!

If the file does not have an empty line, then there is an error when loading lines from a file (94 line).
I understand that the algorithm will also not take into account the last line?

[raygard]

@stabud, Yes, there is a bug if the last line has no newline. I think that's what you're reporting. Is it? What do you mean by empty line?

I am working on a fix but I'm finding it hard to get this function correct. I'll fix this as soon as I can get this right.

What do you mean about "not take into account the last line?" I test with two files where the last lines match, or don't match, or one file or the other has the last line "missing" versus the other file. Those cases all work. What case do you have in mind where the algorithm does not take into account the last line? Do you have a test case for me?

[stabud]

Hi Ray!

I just suggested that the last lines may not be taken into account by the algorithm. In fact, I just wanted you to pay attention to this when correcting the problem of loading lines from the file.
The fact is that I made download from the file differently (first I load the entire file at once, and then break it into lines). In my case, the last line is not taken into account by the algorithm, it is possible only for me. I found a simple solution, add the line additionally at the end (when dividing the buffer into lines). Something like this:

fd.nlines++
fd.lines[fd.nlines] = xstrdup("\n")

But you can check if the algorithm will work correctly if it is transferred to it 2 files about such (without \n at the end of the files):

1file    2file
AAA      AAA
BBB      CCC

[raygard]

I think I have the readline() function working right, finally. Much trickier than it should have been. It can now handle missing newline at end of file, and also embedded nul (0) bytes in the data. The diff program cannot handle nul bytes in the data though, so it aborts if it finds any. Also the diff does not handle the missing newline gracefully, the way gnu diff does, but this is just a demo program so I'm probably not going to fix that.
Also, I was using assert() as a general purpose way to abort on "errors", such as unable to open a file. That's sloppy and wrong, as unable to open a file (e.g.) is an exceptional condition that should be properly reported. assert() should really be used to catch true algorithmic errors, conditions that should never occur if the program is correct. At least in my opinion. So I added errif() to handle fatal conditions that can occur "normally" and changed some asserts() (and added some more I think).

[stabud]

Hi Ray!

but this is just a demo program

You are great that even for demo programs you pay so much attention to testing and fixing. I report bugs only because I want to improve your original example.

I ran your example with the new fix and it seems there are no problems reading data from the file.
I noticed something that you might find interesting:

№	FILE 1		|		№	FILE 2
1	ABC		|		1	ABC
2	DEF		|		2	DEF
3	GHI		|		3	GHI
4			|
5			|

Result:

@@ -1,3 +1,4 @@
 ABC
 DEF
-GHI+GHI
+

It seems to me that the last line (5) is not taken into account.

[raygard]

Looks like you are diffing file2 vs file1 (instead of file1 vs file2). Like diff file2 file1. And file2 is missing its final newline on the GHI line. But I can't duplicate your result. Can you please supply either the exact files themselves or hex dumps of both files?
Here are my versions:

ray@radon:/mnt/e/r/lcsdiff$ od -tx1z -Ax file1
000000 41 42 43 0a 44 45 46 0a 47 48 49 0a 0a 0a        >ABC.DEF.GHI...<
00000e
ray@radon:/mnt/e/r/lcsdiff$ od -tx1z -Ax file2
000000 41 42 43 0a 44 45 46 0a 47 48 49                 >ABC.DEF.GHI<
00000b
ray@radon:/mnt/e/r/lcsdiff$

and here's my output:

ray@radon:/mnt/e/r/lcsdiff$ ./diff file2 file1
--- file2       2025-07-02 10:21:56 -0600
+++ file1       2025-07-02 10:12:45 -0600
@@ -1,3 +1,5 @@
 ABC
 DEF
-GHI+GHI
+
+
ray@radon:/mnt/e/r/lcsdiff$

I get similar output even when the last line of file1 is a space with no newline:

ray@radon:/mnt/e/r/lcsdiff$ od -tx1z -Ax file1
000000 41 42 43 0a 44 45 46 0a 47 48 49 0a 20 0a 20     >ABC.DEF.GHI. . <
00000f
ray@radon:/mnt/e/r/lcsdiff$ ./diff file2 file1
--- file2       2025-07-02 10:21:56 -0600
+++ file1       2025-07-02 10:27:42 -0600
@@ -1,3 +1,5 @@
 ABC
 DEF
-GHI+GHI
+
+ ray@radon:/mnt/e/r/lcsdiff$

Are you sure your file1 has 5 lines?

Incidentally I tweaked the readline() function to shorten and simplify it since yesterday but both versions should work alike.

[stabud]

Hi Ray!

I ask you to forgive me. It seems I got confused. Indeed, you are right. I looked in the editor, it showed 5 lines, but of course in reality there are only 4 lines, the editor simply interprets the symbol EOL as a new line (the fifth), which in fact does not exist yet.

[stabud]

Hi Ray!

I don't know where to write, so I'll write here.
I managed to create my plugin using your code. I didn't forget about you and put you as a co-author. You are mentioned:

1. In the source code (your license + link to github)
2. In the editor help (CHM file)
3. Description of the plugin
4. On the editor's website: https://iupfbeditor.sourceforge.io/description.html
5. Here: https://www.freebasic.net/forum/viewtopic.php?p=308012#p308012