From: Tor Didriksen
Date: January 25 2012 3:07pm
Subject: bzr push into mysql-5.5 branch (tor.didriksen:3705 to 3706) Bug#13463415
List-Archive: http://lists.mysql.com/commits/142547
X-Bug: 13463415
Message-Id: <201201251507.q0PF7e6P012275@acsmt357.oracle.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

 3706 Tor Didriksen	2012-01-25
      Bug#13463415 followup: compensate for compiler bug

    modified:
      sql/item.cc
 3705 Tor Didriksen	2012-01-25
      Bug#13463415 63502: INCORRECT RESULTS OF BIGINT AND DECIMAL COMPARISON
      Bug#11758543 50756: BIGINT '100' MATCHES 1.001E2
      
      Expressions of the form
            BIGINT_COL <compare> <non-integer constant>
      
            should be done either as decimal, or float.
      
            Currently however, such comparisons are done as int,
            which means that the constant may be truncated,
            and yield false positives/negatives for all queries
            where compare is '>' '<' '>=' '<=' '=' '!='.
      
            BIGINT_COL IN <list of contstants>
            and
            BIGINT_COL BETWEEN <constant> AND <constant>
            are also affected.
     @ mysql-test/r/bigint.result
        New tests.
     @ mysql-test/r/func_in.result
        BIGINT <=> string comparison should be done as float,
        so a warning for the value 'abc' is appropriate.
     @ mysql-test/t/bigint.test
        New tests.
     @ sql/item_cmpfunc.cc
        In convert_constant_item() we verify that the constant item
        can be stored in the given field.
        For BIGINT columns (MYSQL_TYPE_LONGLONG) we must verify that the
        stored constant value is actually comparable as int,
        i.e. that the value was not truncated.
        
        For between: compare as int only if both arguments convert correctly to int.

    modified:
      mysql-test/r/bigint.result
      mysql-test/r/func_in.result
      mysql-test/t/bigint.test
      sql/item_cmpfunc.cc
=== modified file 'sql/item.cc'
--- a/sql/item.cc	2012-01-12 09:02:51 +0000
+++ b/sql/item.cc	2012-01-25 15:05:27 +0000
@@ -7399,9 +7399,13 @@ void resolve_const_item(THD *thd, Item *
           or less than the original Item. A 0 may also be returned if 
           out of memory.          
 
-  @note We only use this on the range optimizer/partition pruning,
+  @note We use this in the range optimizer/partition pruning,
         because in some cases we can't store the value in the field
         without some precision/character loss.
+
+        We similarly use it to verify that expressions like
+        BIGINT_FIELD <cmp> <literal value>
+        is done correctly (as int/decimal/float according to literal type).
 */
 
 int stored_field_cmp_to_item(THD *thd, Field *field, Item *item)
@@ -7459,10 +7463,15 @@ int stored_field_cmp_to_item(THD *thd, F
     field_val= field->val_decimal(&field_buf);
     return my_decimal_cmp(item_val, field_val);
   }
-  double result= item->val_real();
+  /*
+    The patch for Bug#13463415 started using this function for comparing
+    BIGINTs. That uncovered a bug in Visual Studio 32bit optimized mode.
+    Prefixing the auto variables with volatile fixes the problem....
+  */
+  volatile double result= item->val_real();
   if (item->null_value)
     return 0;
-  double field_result= field->val_real();
+  volatile double field_result= field->val_real();
   if (field_result < result)
     return -1;
   else if (field_result > result)

No bundle (reason: useless for push emails).