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

[kevans]

Summary

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

Admittedly, I don't know what the "behavior of the original code" is that this is trying to maintain, but this actively broke patching of net/rubygem-grpc at the very least. If this is wrong, I have an alternative patch to make this fallback to plan B, but I don't see any reason for this NUL check.

I will be requested an exp-run for this, but a couple of test patches using plan A worked just fine.

[kevans]

exp-run requested: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224842

[emaste]

Out of curiosity why are there NUL bytes in the first place?

[kevans]

In D13738#287497, @emaste wrote:

Out of curiosity why are there NUL bytes in the first place?

I have no clue. If I understood @swills correctly, it's been this way since this port was created and this is a gemspec produced by some Google{r,-tool}. I guess it must be a valid delimiter, given that it's been this way for so long.

I should also note that gpatch(1) is ok with the patch makepatch created and subsequently fail to apply. The patch (that I failed to actually link to here) can be found in the ports patch on the exp-run.

[kevans]

The associated exp-run is now completed.