MySQL Bugs: #12860: Difference in zero padding of exponent between Unix and Windows

Bug #12860	Difference in zero padding of exponent between Unix and Windows
Submitted:	29 Aug 2005 21:01	Modified:	25 Jan 20:56
Reporter:	Kent Boortz
Status:	Closed
Category:	Server	Severity:	S3 (Non-critical)
Version:	4.1, 5.0	OS:	Microsoft Windows (Windows)
Assigned to:	Alexey Kopytov	Target Version:	5.0+
Triage:	D4 (Minor)

Description:
Floating point values are output differently on Unix and Windows,
caused by a difference in padding of the exponent part. On Unix
the exponent is always two digits, padded with zero if needed, on
Windows tree digits padded with zeroes if needed.

While this is not that serious, it is the same value, this causes
inconsistency for tools used, one being the mysql-test test tool.
It uses a simplistic compare of the expected output and the actual
output, and this fails because of formatting differences.

How to repeat:
Run the mysql-test-run.pl script on Unix and Windows, using a test
case that outputs a float like

  create table t1 (c char(6));
  insert into t1 values (2e6),(2e-5);
  select * from t1;

that on Unix will output

  c
  2e+06
  2e-05

but on Windows will give

  c
  2e+006
  2e-005

Suggested fix:
Use the same output function on Unix and Windows, that use the
same padding. If any padding is to be used in the output at all.

the problem here is that *printf() functions in the vc library always use three digits for
the exponent, but glibc (and other unix c library implementations) only use a third digit
when necessary.

short of switching to our own *printf() implementation, i'm not sure how we can address
this.

I found that I have an old unfinished patch, not sure if it
fully solves the problem or if it is good enough.

===== libmysql/libmysql.c 1.290 vs edited =====
--- 1.290/libmysql/libmysql.c   2005-02-22 14:08:06 +01:00
+++ edited/libmysql/libmysql.c  2005-10-09 00:29:54 +02:00
@@ -3587,6 +3587,17 @@
       sprintf(buff, "%-*.*g", (int) min(sizeof(buff)-1,
                                         param->buffer_length),
              min(14,width), value);
+#ifdef __WIN__
+      {
+        char *exp_p= strpbrk(buff+1, "+-"); /* Skip possibly initial +/- */
+        if (exp_p++ && *exp_p == '0')
+        {
+          /* VC++ sprintf() has minimum three digits exponent, Unix two */
+          *(exp_p++) = *(exp_p + 1);
+          *(exp_p++) = *(exp_p + 1);
+        }
+      }
+#endif
       end= strcend(buff, ' ');
       *end= 0;
     }

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/39547

ChangeSet@1.2521, 2007-12-07 19:56:17+03:00, kaa@polly.(none) +48 -0
  WL #2934 "Make/find library for doing float/double to string conversions
  and vice versa"
  Initial import of the dtoa.c code and custom wrappers around it to allow
  its usage from the server code.
  
  Conversion of FLOAT/DOUBLE values to DECIMAL ones or strings and vice
  versa has been significantly reworked. As the new algoritms are more
  precise than the older ones, results of such conversions may not always
  match those obtained from older server versions. This in turn may break
  compatibility for some applications.
  
  This patch also fixes the following bugs:
  - bug #12860 "Difference in zero padding of exponent between Unix and
  Windows"
  - bug #21497 "DOUBLE truncated to unusable value"
  - bug #26788 "mysqld (debug) aborts when inserting specific numbers into
  char fields"
  - bug #24541 "Data truncated..." on decimal type columns without any
  good reason"

Pushed into 6.0.5-alpha

Pushed into 5.1.23-rc

Pushed into 5.0.54

Fixed in 5.0/5.1 by the patch for bug #26788. Fixed in 6.0 by the patch for WL #2934.

Pushed into 6.0.5-alpha

Noted in 5.0.54, 5.1.23, 6.0.5 changelogs.

Zero-padding of exponent values was not the same across platforms.