Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 11 Jan 2018 15:02:43 +0000
From:      bugzilla-noreply@freebsd.org
To:        freebsd-ports-bugs@FreeBSD.org
Subject:   [Bug 224842] [exp-run] patch(1) change to fix net/rubygem-grpc patching
Message-ID:  <bug-224842-13-tpmGtjigta@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-224842-13@https.bugs.freebsd.org/bugzilla/>
References:  <bug-224842-13@https.bugs.freebsd.org/bugzilla/>

next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D224842

--- Comment #4 from commit-hook@freebsd.org ---
A commit references this bug:

Author: kevans
Date: Thu Jan 11 15:01:48 UTC 2018
New revision: 327826
URL: https://svnweb.freebsd.org/changeset/base/327826

Log:
  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 proc=
ess
  the entire file due to a NUL byte, but I deemed this to be the better opt=
ion
  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

Changes:
  head/usr.bin/patch/inp.c

--=20
You are receiving this mail because:
You are on the CC list for the bug.=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-224842-13-tpmGtjigta>