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

mysqltest.test on Solaris and Mac. write_file produced nice files with all zeroes.

into  mysql.com:/usr/home/ram/work/bug23254/my41-bug23254

We don't set null_value to 0 in the Item_func_compress::val_str() for 
not-NULL results.

Now also detects "source nnnn;" command, previous version only detected
"--source"

Improve function that finds the reason why test was skipped, the old version only looked at the ast line, but there might be some additional debug info there so it's better to scan the whole file. 
There should be only one line that says "reason: <reason>"

This will hopefully avoiid annoying crashes when running with --debug
Fix warnings  from the above in mysqltest.c

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

Fix warning about value from "*ptr++" not being used. Changed it to ptr++ 

into  polly.local:/home/kaa/src/maint/m41-maint--07OGk

MOve DBUG_ASSERT(result_file_name) to after DBUG_ENTER
Change type of "reconnect" variable from int to my_bool, reconnect didn't work on Solaris without that

Add DBUG_PRINT to show the value of mysql->reconnect

into  polly.local:/home/kaa/src/maint/m41-maint--07OGk

into  polly.local:/home/kaa/src/maint/m41-maint--07OGk

'run_testcase_need_master/slave_restart'
Remove the faulty qw
Only look for mysql_fix_privilege_tables if not windows

into  example.com:/work/bug23074/my41-bug23074

into  polly.local:/home/kaa/src/maint/m41-maint--07OGk

into  polly.local:/home/kaa/src/maint/m41-maint--07OGk

set. This has always worked because when flag is !=0 then
HA_VAR_LENGTH_KEY is always set. Therefore, a test case cannot
reveal a faulty behavior.

Fix for bug#23074: typo in myisam/sort.c

The bug is present only in 4.1, will be null-merged to 5.0

For InnoDB, check value of thd->transaction.all.innodb_active_trans instead of thd->transaction.stmt.innobase_tid to see if we really need to rollback.

into  naruto.:C:/cpp/mysql-4.1-maint

into  zippy.cornsilk.net:/home/cmiller/work/mysql/bug17583/my41-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.