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

[Sergei Golubchik]

Hi!

On Jun 20, kgeorge@stripped wrote:
> 
> 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.

You're saying that the problem was caused by strict aliasing.
And the analysis in bug#28400 says about "unsafe aliasing
of doubles/floats vs. int64s". I don't see it in the code. There's no
cast of ulonglong* to float* or vice versa. All I see is a cast of char*
buffer to float*, but according to gcc manual "a character type may
alias any other type", thus it is no problem to modify a float variable
via char* pointer.
 
Regards / Mit vielen Grüssen,
Sergei

-- 
   __  ___     ___ ____  __
  /  |/  /_ __/ __/ __ \/ /   Sergei Golubchik <serg@stripped>
 / /|_/ / // /\ \/ /_/ / /__  Principal Software Developer
/_/  /_/\_, /___/\___\_\___/  MySQL GmbH, Radlkoferstr. 2, D-81373 München
       <___/                  Geschäftsführer: Kaj Arnö - HRB
München 162140