@JlKmn I don't suppose you could cast your eyes over this to make sure we haven't misunderstood anything?

@milkshakeuk no problem I will take a look soon

also i will do another last fuzzing run with a new server cluster I have access to now after the pr is done

@AMCN41R @JlKmn the Linux build and test action is still failing on this PR, one of the (bad) inputs, most likely a line endings git checkout issue?
Before this gets merged it would be good if we can fix this, it might require a tweak to the .gitattributes and maybe easier to debug on Linux or on windows 10 with WSL.

@milkshakeuk
From here

On unix/linux, every line in a file has an End-Of-Line (EOL) character and the EOF character is after the last line. On windows, each line has an EOL characters except the last line. So unix/linux file's last line is
stuff, EOL, EOF
whereas windows file's last line, if the cursor is on the line, is
stuff, EOF

So even though there is no newline character in the file, in Linux there is an extra 0x0A Byte at the end. That's what makes the difference i think. A .gitattributes for the BadInputs Folder could work.

Now that I think about it the correct exception for the bug is NullReference since the Fuzzing results are from Linux. The problem is with debugging these on Windows with the extra linux newline at the end missing. It just wasn't a difference maker in any of the other testcases. We just need to add an extra newline at the end when debugging under Windows. The .gitattributes can stay the same.

So i think the fix is simply adding \n after the ReadAllText in the BadInputTests
var text = File.ReadAllText(path) + "\n";
And then set the exception type to NullReference or fix the exception and set it to HL7

@AMCN41R I was wrong, i think we need a .gitattributes. The Linux Tests now have \n\n at the end, they need to always have Windows file ending without \n.

Also for the handed gracefully function adding the \n is missing

@AMCN41R I was wrong, I think we need a .gitattributes. The Linux Tests now have \n\n at the end, they need to always have Windows file ending without \n.

@AMCN41R @JlKmn I don't think manually adding \n to the end of the input via code in the test is the right thing to do.

It might be easier to commit the files from source unmodified (using git on Linux) but instruct git via .gitattributes to treat them as binary rather than text, this will prevent the test input files line endings from being normalized regardless of their content.

This should ensure we get the same result regardless of running the tests on windows or Linux... then we can fix the parser 😁.

maybe add and commit something like this to .gitattributes before adding and committing the test data files.

tests/NHapi.NUnit/TestData/BadInputs/**/*   -text

This should instruct git to prevent attempting to normalize the files regardless of content.

@milkshakeuk ok I will add the additional Fuzz Results from my last run as an issue. not that many crash inputs.

Unit Test Results

       5 files     103 suites   16s ⏱️
   926 tests    920 ✔️   6 💤 0 ❌
1 797 runs  1 786 ✔️ 11 💤 0 ❌

Results for commit 12aafec.