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

Authored by kevans on Jan 2 2018, 5:50 PM.



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.

Diff Detail

rS FreeBSD src repository
Automatic diff as part of commit; lint not applicable.
Automatic diff as part of commit; unit tests not applicable.
kevans created this revision.Jan 2 2018, 5:50 PM
emaste added a comment.Jan 2 2018, 8:24 PM

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

kevans added a comment.Jan 3 2018, 5:26 AM

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.

The associated exp-run is now completed.

emaste accepted this revision.Jan 11 2018, 3:08 AM
This revision is now accepted and ready to land.Jan 11 2018, 3:08 AM
pfg accepted this revision.Jan 11 2018, 2:28 PM
This revision was automatically updated to reflect the committed changes.