into  zippy.cornsilk.net:/home/cmiller/work/mysql/bug17583/my51-bug17583

Porting forward tests to replacement files.

into  zippy.cornsilk.net:/home/cmiller/work/mysql/bug17583/my50-bug17583

When the client program had its stdout file descriptor closed by the calling
shell, after some amount of work (enough to fill a socket buffer) the server 
would complain about a packet error and then disconnect the client.

This is a serious security problem.  If stdout is closed before the mysql is
exec()d, then the first socket() call allocates file number 1 to communicate
with the server.  Subsequent write()s to that file number (as when printing
results that come back from the database) go back to the server instead in 
the command channel.  So, one should be able to craft data which, upon being
selected back from the server to the client, and injected into the command
stream become valid MySQL protocol to do something nasty when sent /back/ to 
the server.

The solution is to close explicitly the file descriptor that we *printf() to, 
so that the libc layer and the OS layer both agree that the file is closed.

into  neptunus.(none):/home/msvensson/mysql/mysql-5.1-new-maint

  After merge fix.
field.cc:
  After merge fix

into  neptunus.(none):/home/msvensson/mysql/mysql-5.1-new-maint

into  moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.1-real-bug21726

into  neptunus.(none):/home/msvensson/mysql/mysql-5.1-new-maint

into  neptunus.(none):/home/msvensson/mysql/mysql-5.1-new-maint

into  mysql.com:/usr/home/bar/mysql-5.0-rpl

into  mysql.com:/usr/home/bar/mysql-4.1-rpl

into  mysql.com:/usr/home/ram/work/bug22271/my51-bug22271

into  mysql.com:/usr/home/ram/work/bug22271/my51-bug22271

into  neptunus.(none):/home/msvensson/mysql/mysql-5.1-new-maint

into  siva.hindu.god:/usr/home/tim/m/bk/wl3516/51

into  mockturtle.local:/home/dlenev/src/mysql-5.1-rt-merge

into  moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.1-real-bug21726

into  mockturtle.local:/home/dlenev/src/mysql-5.1-rt-merge

into  neptunus.(none):/home/msvensson/mysql/mysql-5.0-maint

into  moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.1-bug21081

into  mysql.com:/users/lthalmann/bkroot/mysql-5.1-new-rpl

into  mysql.com:/users/lthalmann/bk/MERGE/mysql-5.1-merge

into  mysql.com:/users/lthalmann/bk/MERGE/mysql-5.0-merge

into  romeo.(none):/home/bk/fix-mysql-5.1-new-rpl

When compiling with qcc on QNC the define __GNUC__will be set although it doesn't support full GNU syntax
 - disable __attribute__ when using qcc

Adding test case.

into  neptunus.(none):/home/msvensson/mysql/mysql-4.1-maint

into  neptunus.(none):/home/msvensson/mysql/mysql-4.1-maint

into  moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.1-real-bug21726

Non-upper-level INSERTs (the ones in the body of stored procedure,
stored function, or trigger) into a table that have AUTO_INCREMENT
column didn't affected the result of LAST_INSERT_ID() on this level.

The problem was introduced with the fix of bug 6880, which in turn was
introduced with the fix of bug 3117, where current insert_id value was
remembered on the first call to LAST_INSERT_ID() (bug 3117) and was
returned from that function until it was reset before the next
_upper-level_ statement (bug 6880).

The fix for bug#21726 brings back the behaviour of version 4.0, and
implements the following: remember insert_id value at the beginning
of the statement or expression (which at that point equals to
the first insert_id value generated by the previous statement), and
return that remembered value from LAST_INSERT_ID() or @@LAST_INSERT_ID.

Thus, the value returned by LAST_INSERT_ID() is not affected by values
generated by current statement, nor by LAST_INSERT_ID(expr) calls in
this statement.

Version 5.1 does not have this bug (it was fixed by WL 3146).

into  mysql.com:/home/svoj/devel/mysql/merge/mysql-5.1-engines

into  mysql.com:/home/svoj/devel/mysql/merge/mysql-5.1-engines