grep-2.24 released [stable]

[Jim Meyering]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

This is to announce grep-2.24, a stable bug-fix-only release.
This release, so soon after 2.23, was prompted by the discovery
of two bugs related to the --null-data (-z) option.
These bugs were introduced in 2010 and 2002 respectively.

There have been 8 commits by 2 people in the 5 weeks since 2.23.

See the NEWS below for a brief summary.

Thanks to everyone who has contributed!
The following people contributed changes to this release:

  Jim Meyering (7)
  Paul Eggert (1)

Jim [on behalf of the grep maintainers]
==================================================================

Here is the GNU grep home page:
    http://gnu.org/s/grep/

For a summary of changes and contributors, see:
  http://git.sv.gnu.org/gitweb/?p=grep.git;a=shortlog;h=v2.24
or run this command from a git-cloned grep directory:
  git shortlog v2.23..v2.24

Here are the compressed sources and a GPG detached signature[*]:
  http://ftp.gnu.org/gnu/grep/grep-2.24.tar.xz
  http://ftp.gnu.org/gnu/grep/grep-2.24.tar.xz.sig

Use a mirror for higher download bandwidth:
  http://ftpmirror.gnu.org/grep/grep-2.24.tar.xz
  http://ftpmirror.gnu.org/grep/grep-2.24.tar.xz.sig

[*] Use a .sig file to verify that the corresponding file (without the
.sig suffix) is intact.  First, be sure to download both the .sig file
and the corresponding tarball.  Then, run a command like this:

  gpg --verify grep-2.24.tar.xz.sig

If that command fails because you don't have the required public key,
then run this command to import it:

  gpg --keyserver keys.gnupg.net --recv-keys 7FD9FCCB000BEEEE

and rerun the 'gpg --verify' command.

This release was bootstrapped with the following tools:
  Autoconf 2.69.147-5ad35
  Automake 1.99a
  Gnulib v0.1-697-gcd6a452

==================================================================
NEWS

* Noteworthy changes in release 2.24 (2016-03-10) [stable]

** Bug fixes

  grep -z would match strings it should not.  To trigger the bug, you'd
  have to use a regular expression including an anchor (^ or $) and a
  feature like a range or a backreference, causing grep to forego its DFA
  matcher and resort to using re_search.  With a multibyte locale, that
  matcher could mistakenly match a string containing a newline.
  For example, this command:
    printf 'a\nb\0' | LC_ALL=en_US.utf-8 grep -z '^[a-b]*b'
  would mistakenly match and print all four input bytes.  After the fix,
  there is no match, as expected.
  [bug introduced in grep-2.7]

  grep -Pz now diagnoses attempts to use patterns containing ^ and $,
  instead of mishandling these patterns.  This problem seems to be
  inherent to the PCRE API; removing this limitation is on PCRE's
  maint/README wish list.  Patterns can continue to match literal ^
  and $ by escaping them with \ (now needed even inside [...]).
  [bug introduced in grep-2.5]

also posted as:
  https://savannah.gnu.org/forum/forum.php?forum_id=8477
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJW4mBYAAoJEH/Z/MsAC+7uKysP/A02SHrOFPKX/0wPKkni+Uu/
lYw3ystaa1Q0Rlu9KjYE7bJ4cCmJwzwOcVQoPVT0Y5MVz855cjCBVrsg0+VTGoPN
NAE338LuPK6isy9Le6p5Bp51pKYHudghcaL3yjfD/gSuw3cDQzQA0RPB7vNoPPnr
Gvm66uOk90HdEZ0tYM+px0LNyOuEAHB7ZsT+GTuknAP8gUnrssPfcyETe3RRSdni
1cv7DQTHSH8MBT+kEjSGti2CPJKFVrn6a1IW01en70sDKPqWGetDloSjs6T5nk/b
53S+xWu8t9zif0hd6h3myhvXv0BDqK7D2i4UjK1wv5t/Za0GF9Rn2AQ2jeqgrG/B
d/WAVWRaioIzrEo7Ie58KelSA5LBHMBJGvtl2+1xBPkSmPzb8vPsggDmTe+4atsA
kcJ7kt6tAJujcQKxcW+EiV4kYrF67GxV3eUasD73ZrqsuFT8zgSQvziEBSPmUvCk
BK6zoQlWNKOhw+0uLNDF1YL9asPp2bmNC/OcKPjLSlQtVtREyQ19NrWIBOwrL3DW
36//MNeKCD8ndTyM7w/erlpbbR3G0WIyZDhsm8uJCbR7gChCh/GcCZ8ZmCXE0xzt
SDiIkpEjl9SZfqTBsiLwPW+3Mo7tWGS7t/cJoSvMki160BHgbojK2EIUlKBpZ6nI
Iv0mbeOccRjm1S0MkUgO
=8Czg
-----END PGP SIGNATURE-----