Bug #55755 : Date STD variable signness breaks server on FreeBSD and OpenBSD

* Added a check to configure on the size of time_t
* Created a macro to check for a valid time_t that is safe to use with datetime 
  functions and store in TIMESTAMP columns.
* Used the macro consistently instead of the ad-hoc checks introduced by 52315
* Fixed compliation warnings on platforms where the size of time_t is smaller than
  the size of a long (e.g. OpenBSD 4.8 64 amd64).

Bug #52315: utc_date() crashes when system time > year 2037

* Added a correct check for the timestamp range instead of just variable size check to
SET TIMESTAMP.
* Added overflow checking before converting to time_t. 
* Using a correct localized error message in this case instead of the generic error.
* Added a test suite.
* fixed the checks so that they check for unsigned time_t as well. Used the checks 
  consistently across the source code.
* fixed the original test case to expect the new error code.

Fix backported from to 5.0.
"Remove the alignment option, let valgrind use its default"


mysql-test/mysql-test-run-shell.sh:
  Bug #47811 : remove the non-default alignment specification.
    - backport from 5.1
     "Remove the alignment option, let valgrind use its default"
mysql-test/mysql-test-run.pl:
  Bug #47811 : remove the non-default alignment specification.
    - backport from 5.1
     "Remove the alignment option, let valgrind use its default"

Updated the copyright.

Backport to 5.0.

/*![:version:] Query Code */, where [:version:] is a sequence of 5 
digits representing the mysql server version(e.g /*!50200 ... */),
is a special comment that the query in it can be executed on those 
servers whose versions are larger than the version appearing in the 
comment. It leads to a security issue when slave's version is larger 
than master's. A malicious user can improve his privileges on slaves. 
Because slave SQL thread is running with SUPER privileges, so it can
execute queries that he/she does not have privileges on master.
      
This bug is fixed with the logic below: 
- To replace '!' with ' ' in the magic comments which are not applied on
  master. So they become common comments and will not be applied on slave.
      
- Example:
  'INSERT INTO t1 VALUES (1) /*!10000, (2)*/ /*!99999 ,(3)*/
   will be binlogged as
  'INSERT INTO t1 VALUES (1) /*!10000, (2)*/ /* 99999 ,(3)*/

- Removed files specific to compiling on OS/2
- Removed files specific to SCO Unix packaging
- Removed "libmysqld/copyright", text is included in documentation
- Removed LaTeX headers for NDB Doxygen documentation
- Removed obsolete NDB files
- Removed "mkisofs" binaries
- Removed the "cvs2cl.pl" script
- Changed a few GPL texts to use "program" instead of "library"

file .\item_subselect.cc, line 836
     
IN quantified predicates are never executed directly. They are rather wrapped
inside nodes called IN Optimizers (Item_in_optimizer) which take care of the
execution. However, this is not done during query preparation. Unfortunately
the LIKE predicate pre-evaluates constant right-hand side arguments even
during name resolution. Likely this is meant as an optimization.
      
Fixed by not pre-evaluating LIKE arguments in view prepare mode.

Back-ported to 5.0s

The user-visible problem was that changes to column-level privileges,
happened in between of PREPARE and EXECUTE of a prepared statement, were
neglected. I.e. a prepared statement could be executed with the
column-level privileges as of PREPARE-time. The problem existed for
column-level privileges only.

A similar problem existed for stored programs: the changes between
executions didn't have an effect.

Technically the thing is that table references are cached in
Prepared_statement::prepare() call. In subsequent
Prepared_statement::execute() calls those cached values are used.
There are two functions to get a field by name: find_field_in_table() and
find_field_in_table_ref(). On prepare-phase find_field_in_table_ref() is
called, on execute-phase -- find_field_in_table() because the table is
cached. find_field_in_table() does not check column-level privileges and
expects the caller to do that. The problem was that this check was
forgotten.

The fix is to check them there as it happens in find_field_in_table_ref().

Original revid: alexey.kopytov@sun.com-20100723115254-jjwmhq97b9wl932l

 > Bug #54476: crash when group_concat and 'with rollup' in
 >                      prepared statements
 >
 > Using GROUP_CONCAT() together with the WITH ROLLUP modifier
 > could crash the server.
 >
 > The reason was a combination of several facts:
 >
 > 1. The Item_func_group_concat class stores pointers to ORDER
 > objects representing the columns in the ORDER BY clause of
 > GROUP_CONCAT().
 >
 > 2. find_order_in_list() called from
 > Item_func_group_concat::setup() modifies the ORDER objects so
 > that their 'item' member points to the arguments list
 > allocated in the Item_func_group_concat constructor.
 >
 > 3. In some cases (e.g. in JOIN::rollup_make_fields) a copy of
 > the original Item_func_group_concat object could be created by
 > using the Item_func_group_concat::Item_func_group_concat(THD
 > *thd, Item_func_group_concat *item) copy constructor. The
 > latter essentially creates a shallow copy of the source
 > object. Memory for the arguments array is allocated on
 > thd->mem_root, but the pointers for arguments and ORDER are
 > copied verbatim.
 >
 > What happens in the test case is that when executing the query
 > for the first time, after a copy of the original
 > Item_func_group_concat object has been created by
 > JOIN::rollup_make_fields(), find_order_in_list() is called for
 > this new object. It then resolves ORDER BY by modifying the
 > ORDER objects so that they point to elements of the arguments
 > array which is local to the cloned object. When thd->mem_root
 > is freed upon completing the execution, pointers in the ORDER
 > objects become invalid. Those ORDER objects, however, are also
 > shared with the original Item_func_group_concat object which is
 > preserved between executions of a prepared statement. So the
 > first call to find_order_in_list() for the original object on
 > the second execution tries to dereference an invalid pointer.
 >
 > The solution is to create copies of the ORDER objects when
 > copying Item_func_group_concat to not leave any stale pointers
 > in other instances with different lifecycles.


mysql-test/r/func_gconcat.result:
  Test case for bug #54476.
mysql-test/t/func_gconcat.test:
  Test case for bug #54476.
sql/item_sum.cc:
  Copy the ORDER objects pointed to by the elements of the
  'order' array in the copy constructor of
  Item_func_group_concat.
sql/table.h:
  Removed the unused 'item_copy' member of the ORDER class.

Improved error handling such that queries against Information_Schema.Tables won't
fail if a Federated table is unable to connect to remote host.



sql/sql_show.cc:
  If Handler::Info() fails, save error text in TABLE COMMENTS column, clear error.

will not display "indicated result file not found" due to wrongly named
var directory.

 > revision-id: gshchepa@mysql.com-20100801181236-uyuq6ewaq43rw780
 > parent: alexey.kopytov@sun.com-20100723115254-jjwmhq97b9wl932l
 > committer: Gleb Shchepa <gshchepa@mysql.com>
 > branch nick: mysql-5.1-security
 > timestamp: Sun 2010-08-01 22:12:36 +0400
 > Bug #54461: crash with longblob and union or update with subquery
 >
 > Queries may crash, if
 >   1) the GREATEST or the LEAST function has a mixed list of
 >      numeric and LONGBLOB arguments and
 >   2) the result of such a function goes through an intermediate
 >      temporary table.
 >
 > An Item that references a LONGBLOB field has max_length of
 > UINT_MAX32 == (2^32 - 1).
 >
 > The current implementation of GREATEST/LEAST returns REAL
 > result for a mixed list of numeric and string arguments (that
 > contradicts with the current documentation, this contradiction
 > was discussed and it was decided to update the documentation).
 >
 > The max_length of such a function call was calculated as a
 > maximum of argument max_length values (i.e. UINT_MAX32).
 >
 > That max_length value of UINT_MAX32 was used as a length for
 > the intermediate temporary table Field_double to hold
 > GREATEST/LEAST function result.
 >
 > The Field_double::val_str() method call on that field
 > allocates a String value.
 >
 > Since an allocation of String reserves an additional byte
 > for a zero-termination, the size of String buffer was
 > set to (UINT_MAX32 + 1), that caused an integer overflow:
 > actually, an empty buffer of size 0 was allocated.
 >
 > An initialization of the "first" byte of that zero-size
 > buffer with '\0' caused a crash.
 >
 > The Item_func_min_max::fix_length_and_dec() has been
 > modified to calculate max_length for the REAL result like
 > we do it for arithmetical operators.


mysql-test/r/func_misc.result:
  Test case for bug #54461.
mysql-test/t/func_misc.test:
  Test case for bug #54461.
sql/item_func.cc:
  Bug #54461: crash with longblob and union or update with subquery
  
  The Item_func_min_max::fix_length_and_dec() has been
  modified to calculate max_length for the REAL result like
  we do it for arithmetical operators.

Fix formatting issues in README file.

EXCEPTIONS-CLIENT from all the places.

> revision-id: alexey.kopytov@sun.com-20100824103548-ikm79qlfrvggyj9h
> parent: sunny.bains@oracle.com-20100816001222-xqc447tr6jwh8c53
> committer: Alexey Kopytov <Alexey.Kopytov@Sun.com>
> branch nick: 5.1-security
> timestamp: Tue 2010-08-24 14:35:48 +0400
> message:
>   Bug #55568: user variable assignments crash server when used
>               within query
>   
>   The server could crash after materializing a derived table
>   which requires a temporary table for grouping.
>   
>   When destroying the temporary table used to execute a query for
>   a derived table, JOIN::destroy() did not clean up Item_fields
>   pointing to fields in the temporary table. This led to
>   dereferencing a dangling pointer when printing out the items
>   tree later in the outer SELECT.
>   
>   The solution is an addendum to the patch for bug37362: in
>   addition to cleaning up items in tmp_all_fields3, do the same
>   for items in tmp_all_fields1, since now we have an example
>   where this is necessary.


sql/field.cc:
  Make sure field->table_name is not set to NULL in
  Field::make_field() to avoid assertion failure in 
  Item_field::make_field() after cleaning up items
  (the assertion fired in udf.test when running
  the test suite with the patch applied).
sql/sql_select.cc:
  In addition to cleaning up items in tmp_all_fields3, do the
  same for items in tmp_all_fields1.
  Introduce a new helper function to avoid code duplication.
sql/sql_select.h:
  Introduce a new helper function to avoid code duplication in
  JOIN::destroy().

backport from 5.1


mysql-test/r/subselect.result:
  backport from 5.1
mysql-test/t/subselect.test:
  backport from 5.1
sql/sql_select.cc:
  backport from 5.1

Problem: a flaw (derefencing a NULL pointer) in the LIKE optimization
code may lead to a server crash in some rare cases.

Fix: check the pointer before its dereferencing.


mysql-test/r/func_like.result:
  Fix for bug #54575: crash when joining tables with unique set column
    - test result.
mysql-test/t/func_like.test:
  Fix for bug #54575: crash when joining tables with unique set column
    - test case.
sql/item_cmpfunc.cc:
  Fix for bug #54575: crash when joining tables with unique set column
  - check res2 buffer pointer before its dereferencing 
    as it may be NULL in some cases.

Updated the README file.