SELECT TO_DAYS(SEC_TO_TIME(MAKEDATE(0,RAND(~0))));

SELECT SEC_TO_TIME(MAKEDATE(0,RAND(~0)));

SELECT SEC_TO_TIME(CONVERT(900*24*60*60 USING ucs2));

SHOW WARNINGS;

+---------+------+----------------------------------------------------------------------------+

| Level   | Code | Message                                                                    |

+---------+------+----------------------------------------------------------------------------+

| Warning | 1292 | Truncated incorrect time value: '\x007\x007\x007\x006\x000\x000\x000\x000' |

+---------+------+----------------------------------------------------------------------------+

+---------+------+--------------------------------------------+

| Level   | Code | Message                                    |

+---------+------+--------------------------------------------+

| Warning | 1292 | Truncated incorrect time value: '77760000' |

+---------+------+--------------------------------------------+

Item_func_sec_to_time::get_date() calls an args[0]'s value method two times:

- once val_int() or val_decimal() inside Item::get_seconds()

- then val_str() to generate a warning, in case an out-of-range value

This approach was wrong for two reasons:

1. val_str() in some cases can return NULL even if val_int()/val_decimal()

   previously returned a not-NULL value.

   This is possible when args[0] is not deterministic

   (for instance, uses RAND() directly or indirectly).

   This caused the crash reported in the bug:

   the warning generation code in Item_func_sec_to_time::get_date()

   did not expect val_str() to return NULL.

   This patch fixes this problem by checking the result of val_str().

   In case of a non-NULL, the result of val_str() is used as before.

   In case of NULL, the "ulonglong seconds" value is used for the warning.

   Note, "ulong sec_part" value is ignored in the warning for simplicity.

2. Calling val_str() to generate warnings fires the function side effect again.

   For example, consider SEC_TO_TIME(f1()), where f1() is a stored function

   doing some INSERTs as a side effect. If f1() returns an out-of-range value,

   the call for val_str() to generate the warning forces the INSERTs to happen

   again, which is wrong. The side effect must happen only once per call.

   This problem is NOT fixed by this patch to avoid big changes in 5.5.

   This will be fixed separately in 10.3 or 10.4.

Also, passing err->ptr() and err->length() directly to

make_truncated_value_warning() was wrong, because it did not take

into account err->charset(). This caused unreadable warnings in case

of tricky character sets, such as ucs2. This patch fixes this additional

problem by using "ErrConvStr err2(err)".