Fix crash on macOS 10.13 and later.
https://github.com/kjn/lbzip2/issues/20

Upstream is unresponsive so I've backported the fix from gnulib.
https://git.savannah.gnu.org/cgit/gnulib.git/commit/lib/vasnprintf.c?id=c41f233c4c38e84023a16339782ee306f03e7f59
https://git.savannah.gnu.org/cgit/gnulib.git/commit/lib/vasnprintf.c?id=7df04f9b8a0adb1575ca0555775ec10860143cbf
--- lib/vasnprintf.c.orig	2014-03-09 09:46:04.000000000 -0500
+++ lib/vasnprintf.c	2020-08-18 22:29:54.000000000 -0500
@@ -4870,7 +4870,10 @@
 #endif
                   *fbp = dp->conversion;
 #if USE_SNPRINTF
-# if !(((__GLIBC__ > 2 || (__GLIBC__ == 2 && __GLIBC_MINOR__ >= 3)) && !defined __UCLIBC__) || ((defined _WIN32 || defined __WIN32__) && ! defined __CYGWIN__))
+# if ! (((__GLIBC__ > 2 || (__GLIBC__ == 2 && __GLIBC_MINOR__ >= 3))        \
+         && !defined __UCLIBC__)                                            \
+        || (defined __APPLE__ && defined __MACH__)                          \
+        || (defined _WIN32 && ! defined __CYGWIN__))
                 fbp[1] = '%';
                 fbp[2] = 'n';
                 fbp[3] = '\0';
@@ -4884,6 +4887,13 @@
                    in format strings in writable memory may crash the program
                    (if compiled with _FORTIFY_SOURCE=2), so we should avoid it
                    in this situation.  */
+                /* On Mac OS X 10.3 or newer, we know that snprintf's return
+                   value conforms to ISO C 99: the tests gl_SNPRINTF_RETVAL_C99
+                   and gl_SNPRINTF_TRUNCATION_C99 pass.
+                   Therefore we can avoid using %n in this situation.
+                   On Mac OS X 10.13 or newer, the use of %n in format strings
+                   in writable memory by default crashes the program, so we
+                   should avoid it in this situation.  */
                 /* On native Windows systems (such as mingw), we can avoid using
                    %n because:
                      - Although the gl_SNPRINTF_TRUNCATION_C99 test fails,