sql/slave.cc:
  compiler warning fix

mysql-test/r/perror-win.result:
  pushbuild failure fix
mysql-test/t/perror-win.test:
  pushbuild failure fix
sql/item_func.cc:
  pushbuild failure fix

No commit message

The bug is repeatable with latest(1.0.1) InnoDB plugin on Linux, Win,
If MySQL is compiled with valgrind there are errors about
using of uninitialized variable(orig_table).
The fix is to set field->orig_table correct value.


mysql-test/r/innodb_mysql.result:
  test result
mysql-test/t/innodb_mysql.test:
  test case
sql/sql_base.cc:
  set field->orig_table to 'table' value because it may be bogus and
  it leads to crash on Field_string::type() function.

Reason for the failing test was that "SELECT count(*) from mysql.general_log;" was not always
the same number. That was fixed by "...count(*)>4..." as the minimal fulfilled condition.
As Bug 35371 was fixed the testcase with "log_output = 'FILE'" was enabled and changed to have
always the same result.

enable uncacheable flag if we update a view with check option
and check option has a subselect, otherwise, the check option
can be evaluated after the subselect was freed as independent
(See full_local in JOIN::join_free())


mysql-test/r/subselect.result:
  test result
mysql-test/t/subselect.test:
  test case
sql/mysql_priv.h:
  added UNCACHEABLE_CHECKOPTION flag
sql/sql_update.cc:
  enable uncacheable flag if we update a view with check option
  and check option has a subselect, otherwise, the check option
  can be evaluated after the subselect was freed as independent
  (See full_local in JOIN::join_free())

set DATE|DATETIME value to 0 if ALLOW_INVALID_DATES sql_mode is not enabled.


sql/field.cc:
  set DATE|DATETIME value to 0 if ALLOW_INVALID_DATES sql_mode is not enabled.
tests/mysql_client_test.c:
  test case

extended perror to enable printing of Win32 system errors


extra/perror.c:
  extended perror to enable printing of Win32 system errors
mysql-test/r/perror-win.result:
  test result
mysql-test/t/perror-win.test:
  test case

Post-pushbuild fix.

- Windows does not have 'socket' system variable.
- Compiler warning in sql/slave.cc

mysql-test/r/variables.result:
  Bug#28234 - global/session scope - documentation vs implementation
  Updated test result.
mysql-test/t/variables.test:
  Bug#28234 - global/session scope - documentation vs implementation
  Removed test for 'socket' variable. Windows doesn't have it.
sql/slave.cc:
  Bug#28234 - global/session scope - documentation vs implementation
  Changed type of constant to avoid a compiler warning.

(no conflicts)

We pretended that TIMEDIFF() would always return positive results;
this gave strange results in comparisons of the TIMEDIFF(low,hi)<TIME(0)
type that rendered a negative result, but still gave false in comparison.
We also inadvertantly dropped the sign when converting times to
decimal.

CAST(time AS DECIMAL) handles signs of the times correctly.
TIMEDIFF() marked up as signed. Time/date comparison code switched to
signed for clarity.

mysql-test/r/func_sapdb.result:
  show that time-related comparisons work with negative
  time values now.
  show that converting time to DECIMAL no longer drops sign.
mysql-test/t/func_sapdb.test:
  show that time-related comparisons work with negative
  time values now.
  show that converting time to DECIMAL no longer drops sign.
sql/item_cmpfunc.cc:
  signed returns
sql/item_cmpfunc.h:
  signed now (time/date < > =)
sql/item_func.cc:
  signed now
sql/item_timefunc.h:
  Functions such as TIMEDIFF() return signed results!
  The file-comments pretended we were doing that all along, anyway...
sql/my_decimal.cc:
  heed sign when converting time to my_decimal;
  times may actually be negative!
  Needed for SELECT CAST(time('-73:42:12') AS DECIMAL);
sql/mysql_priv.h:
  using signed for dates and times now

symlink.test failed when run in an environment that has mysql-test/var
symlinked to elsewhere, e.g. a memory file system. This is the case
when running mysql-test-run --mem.

In this case the server does not detect that the directory specified
with a DATA/INDEX DIRECTORY clause is within its data home directory.
This problem was reported as Bug#39277 (Creation of table with data
and/or index files in data home directory succeeds). It was decided
that it will not be fixed in 5.1. Hence, the current behavior is
accepted for 5.1. It will be fixed in 6.0 though.

Fixed the test case so that it works in both environments. 1. When no
symbolic link is involved, the server notices that the data/index
directory is in its data hone directory and rejects the CREATE/ALTER
TABLE statement. 2. When the data home directory is symlinked, it
does not notice the problem and executes the statement sucessfully.


mysql-test/r/symlink.result:
  Bug#41002 - symlink.test fails on symlinked datadir
  Updated test result.
mysql-test/t/symlink.test:
  Bug#41002 - symlink.test fails on symlinked datadir
  Adjusted the test case to the accepted behavior.
  It needs to accept success and failure of some statements.