grep: fix integer-overflow issues in main program

* NEWS: Document this.
* bootstrap.conf (gnulib_modules): Add inttypes, xstrtoimax.
Remove xstrtoumax.
* src/main.c: Include <inttypes.h>, for INTMAX_MAX, PRIdMAX.
(context_length_arg, prtext, grepbuf, grep, grepfile)
(get_nondigit_option, main):
Use intmax_t, not int, for line counts.
(context_length_arg, main): Silently ceiling line counts
to maximum value, since there's no practical difference between
doing that and using infinite-precision arithmetic.
(out_before, out_after, pending): Now intmax_t, not int.
(max_count, outleft): Now intmax_t, not off_t.
(prepend_args, prepend_default_options, main):
Use size_t, not int, for sizes.
(prepend_default_options): Check for int and size_t overflow.

1 files changed, 5 insertions, 0 deletions

diff --git a/NEWS b/NEWS
index 47e0ca4b..5ff40279 100644
--- a/NEWS
+++ b/NEWS
@@ -11,6 +11,11 @@ GNU grep NEWS                                    -*- outline -*-
   GNU C library's regular expression functions cannot handle such long lines.
   [bug present since "the beginning"]
 
+  The -m, -A, -B, and -C options no longer mishandle context line
+  counts that do not fit in 'int'.  Also, grep -c's counts are now
+  limited by the type 'intmax_t' (typically less than 2**63) rather
+  than 'int' (typically less than 2**31).
+
   grep no longer silently suppresses errors when reading a directory
   as if it were a text file.  For example, "grep x ." now reports a
   read error on most systems; formerly, it ignored the error.