Re: bk commit into 5.0 tree (gkodinov:1.2494) BUG#27383

[Konstantin Osipov]

* kgeorge@stripped <kgeorge@stripped> [07/06/20 13:43]:
> Below is the list of changes that have just been committed into a local
> 5.0 repository of kgeorge. When kgeorge does a push these changes will
> be propagated to the main repository and, within 24 hours after the
> push, to the public repository.
> For information on how to access the public repository
> see http://dev.mysql.com/doc/mysql/en/installing-source-tree.html
> 
> ChangeSet@stripped, 2007-06-20 12:42:21+03:00, gkodinov@stripped +1 -0
>   Bug #27383: Crash in test "mysql_client_test"
>   
>   The C optimizer may decide that data access operations
>   through pointer of different type are not related to 
>   the original data (strict aliasing).
>   This is what happens in fetch_long_with_conversion(),
>   when called as part of mysql_stmt_fetch() : it tries 
>   to check for truncation errors by first storing float
>   (and other types of data) into a char * buffer and then 
>   accesses them through a float pointer.
>   This is done to prevent the effects of excess precision
>   when using FPU registers.
>   Fixed by making the intermediary variables volatile (
>   to not re-introduce the excess precision bug) and using
>   the intermediary value instead of the char * buffer.
>   Note that there can be loss of precision for both signed
>   and unsigned 64 bit integers converted to double and back,
>   so the check must stay there (even for compatibility 
>   reasons).
>   Based on the excellent analysis in bug 28400.

Hi Joro,

Please take a look at some other places where I believe I've been dealing with
this problem before (in December 2004):

case MYSQL_TYPE_FLOAT:
{
  double data= my_strntod(&my_charset_latin1, value, length, &endptr, &err);
  float fdata= (float) data;
  *param->error= (fdata != data) | test(err);
  floatstore(buffer, fdata);
  break;
}

Here we have two variables on stack and do an assignment of
one to another.
Where does the solution with using volatile come from? Is it a 
recommended workaround?
If the old solution works, please use it instead.

-- 
-- Konstantin Osipov              Software Developer, Moscow, Russia
-- MySQL AB, www.mysql.com   The best DATABASE COMPANY in the GALAXY