0b87c9f682
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 |
||
|---|---|---|
| .. | ||
| backupfile.c | ||
| backupfile.h | ||
| common.h | ||
| inp.c | ||
| inp.h | ||
| Makefile | ||
| Makefile.depend | ||
| mkpath.c | ||
| patch.1 | ||
| patch.c | ||
| pathnames.h | ||
| pch.c | ||
| pch.h | ||
| util.c | ||
| util.h | ||