Fix configure's snprintf test so it exposes HP-UX bug.

Since commit e1d19c902, buildfarm member gharial has been failing with
symptoms indicating that snprintf sometimes returns -1 for buffer
overrun, even though it passes the added configure check.  Some
google research suggests that this happens only in limited cases,
such as when the overrun happens partway through a %d item.  Adjust
the configure check to exercise it that way.  Since I'm now feeling
more paranoid than I was before, also make the test explicitly verify
that the buffer doesn't get physically overrun.

1 files changed, 6 insertions, 3 deletions

diff --git a/configure b/configure
index cecd96a14fa..836d68dad37 100755
--- a/configure
+++ b/configure
@@ -16378,8 +16378,8 @@ fi
 # Force use of our snprintf if the system's doesn't handle buffer overrun
 # as specified by C99.
 if test "$pgac_need_repl_snprintf" = no; then
-  { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether snprintf reports buffer overrun per C99" >&5
-$as_echo_n "checking whether snprintf reports buffer overrun per C99... " >&6; }
+  { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether snprintf handles buffer overrun per C99" >&5
+$as_echo_n "checking whether snprintf handles buffer overrun per C99... " >&6; }
 if ${pgac_cv_snprintf_c99_result+:} false; then :
   $as_echo_n "(cached) " >&6
 else
@@ -16395,7 +16395,10 @@ int main()
 {
   char buf[10];
 
-  if (snprintf(buf, sizeof(buf), "12345678901234567890") != 20)
+  strcpy(buf, "abcdefghi");
+  if (snprintf(buf, 4, "%d", 123456) != 6)
+    return 1;
+  if (strcmp(buf, "123") != 0 || buf[4] != 'e')
     return 1;
   return 0;
 }