(Mostly in DBUG_PRINT() and unused arguments)
Fixed bug in query cache when used with traceing (--with-debug)
Fixed memory leak in mysqldump
Removed warnings from mysqltest scripts (replaced -- with #)
(4.1 version, with post-review fixes)
The fix for another Bug (6439) limited FROM_UNIXTIME() to
TIMESTAMP_MAX_VALUE which is 2145916799 or 2037-12-01 23:59:59 GMT,
however unix timestamp in general is not considered to be limited
by this value. All dates up to power(2,31)-1 are valid.
This patch extends allowed TIMESTAMP range so, that max
TIMESTAMP value is power(2,31)-1. It also corrects
FROM_UNIXTIME() and UNIX_TIMESTAMP() functions, so that
max allowed UNIX_TIMESTAMP() is power(2,31)-1. FROM_UNIXTIME()
is fixed accordingly to allow conversion of dates up to
2038-01-19 03:14:07 UTC. The patch also fixes CONVERT_TZ()
function to allow extended range of dates.
The main problem solved in the patch is possible overflows
of variables, used in broken-time representation to time_t
conversion (required for UNIX_TIMESTAMP).
- bug #11655 "Wrong time is returning from nested selects - maximum time exists
- input and output TIME values were not validated properly in several conversion functions
- bug #20927 "sec_to_time treats big unsigned as signed"
- integer overflows were not checked in several functions. As a result, input values like 2^32 or 3600*2^32 were treated as 0
- BIGINT UNSIGNED values were treated as SIGNED in several functions
- in cases where both input string truncation and out-of-range TIME value occur, only 'truncated incorrect time value' warning was produced
if input year for date_add() / date_sub() with INTERVAL is low enough for
calc_daynr() to possibly return incorrect results (calc_daynr() has no information
on whether the year is low because it was a two-digit year ('77) or because it
was a really low four-digit year (0077) and will indiscriminately try to turn the
value into a four-digit year by adding 1900 or 2000 respectively), the functions
will now throw NULL.
- Fixed some error condtion when handling dates with 'T'
- Added extra test for bug #11867 (Wrong result with "... WHERE ROW( a, b ) IN ( SELECT DISTINCT a, b WHERE ...)" to show it's not yet fixed
- Safety fixes and cleanups
Change bool in C code to my_bool
Added to mysqltest --enable_parsning and --disable_parsing to avoid to have to comment parts of tests
Added comparison of LEX_STRING's and use this to compare file types for view and trigger files.
In server we assume that datetime values stored in MYSQL_TIME struct
are normalized (and year is not greater than 9999), so we should
perform range checks in all places then we convert something to
MYSQL_TIME.
