patch(1): Don't check for NUL bytes in Plan A

Plan A mmap()'s the entire input file and operates on it in memory. The
map(2) call succeeded, so we shouldn't need to bother checking for the NUL
byte as long as we're within our buffer space.

This was clearly intentional to match "the behavior of the original code",
but it creates a discrepancy between Plan A and Plan B that doesn't seem
sensible and it's not inherently wrong to allow a NUL byte.

This change was motivated by the gemspec in net/rubygem-grpc failing to
patch, despite the patch being generated with diff, because a NUL byte was
used as a delimiter in the header briefly in an otherwise text file.

An alternative was considered: to fallback to plan B if plan A won't process
the entire file due to a NUL byte, but I deemed this to be the better option
since plan A isn't failing due to memory limitations and will fail later on
if it's really dealing with a file it shouldn't be.

PR:		224842 (exp-run)
Reported by:	swills
Reviewed by:	emaste, pfg
MFC after:	2 weeks
Differential Revision:	https://reviews.freebsd.org/D13738

1 files changed, 5 insertions, 2 deletions

diff --git a/usr.bin/patch/inp.c b/usr.bin/patch/inp.c
index 2c955d0c8377..6a01f782ce62 100644
--- a/usr.bin/patch/inp.c
+++ b/usr.bin/patch/inp.c
@@ -213,8 +213,11 @@ plan_a(const char *filename)
 	/* now scan the buffer and build pointer array */
 	iline = 1;
 	i_ptr[iline] = i_womp;
-	/* test for NUL too, to maintain the behavior of the original code */
-	for (s = i_womp, i = 0; i < i_size && *s != '\0'; s++, i++) {
+	/*
+	 * Testing for NUL here actively breaks files that innocently use NUL
+	 * for other reasons. mmap(2) succeeded, just scan the whole buffer.
+	 */
+	for (s = i_womp, i = 0; i < i_size; s++, i++) {
 		if (*s == '\n') {
 			if (iline == lines_allocated) {
 				if (!reallocate_lines(&lines_allocated))