Removing variant expected-output files for float-output differences - Mailing list pgsql-hackers

In the wake of commit 6eb3eb577, I believe we have no remaining buildfarm
animals that don't handle minus zero per spec.  gaur is the only one that
was failing on the minus-zero-dependent geometry test cases introduced by
a3d284485, and I've already verified that this makes it pass again.

I think therefore that we ought to remove the variant regression test
output files that are there only to cater for failing to print minus zero
as such.  AFAICT the ones meeting that description are numerology_1.out
and float8-small-is-zero_1.out.  If we keep them, we're morally obliged
to also cater for no-minus-zero in the geometry tests, and I don't think
we really want to, especially if we have no way to verify the variant
file.

(It might also be interesting to see what happens if we remove geo_ops.c's
hacks to avoid minus zero results.  But that's not what I'm on about
today.)

Also, we have quite a few variant expected-files that exist only to cater
for Windows' habit of printing three exponent digits where everybody else
prints just two.  It struck me that it would not be hard, or expensive,
to undo that choice in snprintf.c (see attached untested patch).  So we
could considerably reduce future maintenance pain for the affected tests
by getting rid of those files.

As against that, Windows users might possibly complain that float output
looks different than they're used to.  I'm not sure how much sympathy
I have for that position.  If we reimplement float output for more speed,
as is under discussion in nearby threads, I doubt we'd trouble to preserve
this Windows-ism in the rewrite.

Comments?

            regards, tom lane

diff --git a/src/port/snprintf.c b/src/port/snprintf.c
index 58300ea..0eb70c2 100644
--- a/src/port/snprintf.c
+++ b/src/port/snprintf.c
@@ -1173,6 +1173,22 @@ fmtfloat(double value, char type, int forcesign, int leftjust,
         }
         if (vallen < 0)
             goto fail;
+
+        /*
+         * Windows, alone among our supported platforms, likes to emit
+         * three-digit exponent fields even when two digits would do.  Hack
+         * such results to look like the way everyone else does it.
+         */
+#ifdef WIN32
+        if (vallen >= 6 &&
+            convert[vallen - 5] == 'e' &&
+            convert[vallen - 3] == '0')
+        {
+            convert[vallen - 3] = convert[vallen - 2];
+            convert[vallen - 2] = convert[vallen - 1];
+            vallen--;
+        }
+#endif
     }

     padlen = compute_padlen(minlen, vallen + zeropadlen, leftjust);
@@ -1290,6 +1306,17 @@ pg_strfromd(char *str, size_t count, int precision, double value)
                 target.failed = true;
                 goto fail;
             }
+
+#ifdef WIN32
+            if (vallen >= 6 &&
+                convert[vallen - 5] == 'e' &&
+                convert[vallen - 3] == '0')
+            {
+                convert[vallen - 3] = convert[vallen - 2];
+                convert[vallen - 2] = convert[vallen - 1];
+                vallen--;
+            }
+#endif
         }
     }