mi_write valgrind warning in alias test

We were getting this Valgrind warning in the alias test:

==16136== Thread 16:
==16136== Syscall param pwrite64(buf) points to uninitialised byte(s)
==16136== at 0x76D2B08: ??? (in /lib/libpthread-2.10.1.so)
==16136== by 0x818AD9: my_pwrite (my_pread.cc:106)
==16136== by 0x7FAEFC: mi_nommap_pwrite (mi_dynrec.cc:231)
==16136== by 0x7FD054: _mi_write_part_record (mi_dynrec.cc:743)
==16136== by 0x7FB2DD: write_dynamic_record(st_myisam_info*, unsigned char const*, unsigned long) (mi_dynrec.cc:354)
==16136== by 0x7FB08E: _mi_write_blob_record (mi_dynrec.cc:273)
==16136== by 0x814C04: mi_write (mi_write.cc:126)
==16136== by 0x7DE922: ha_myisam::write_row(unsigned char*) (ha_myisam.cc:631)
==16136== by 0x5E5DAD: Cursor::ha_write_row(unsigned char*) (cursor.cc:1765)
==16136== by 0x564136: write_record(Session*, Table*, st_copy_info*) (sql_insert.cc:914)
==16136== by 0x562E33: mysql_insert(Session*, TableList*, List<Item>&, List<List<Item> >&, List<Item>&, List<Item>&, enum_duplicates, bool) (sql_insert.cc:388)


for this query in alias.test:
INSERT INTO t1 VALUES (3359356,405,3359356,'Mustermann Musterfrau',52500,'2000-05-20','workflow','Auftrag erledigt','Originalvertrag eingegangen und geprft','','privat',1485525,2122316,'+','','N',1909160,'MobilComSuper92000D2',NULL,NULL,'MS9ND2',3,24,'MobilCom Shop Koeln',52500,NULL,'auto','2001-02-02 10:59:16','Mobilfunk','PP','','','');

The table definition has 33 fields, 13 of which are NULLable.
This means we have 2 bytes for the NULL bitmap at the start of the row.

For some reason that escapes most sane people, we had a check to see if
session->used_tables was set, and only if it was restore the default
record to table->record[0]. Otherwise, we'd clear the delete marker....
which is the lovely obscure darn bit that may be added to the front
of the record iff it's a packed record. Of course, instead of flipping the
bit, we'd copy the byte. This has the lovely characteristic of having things
work fine for tables with up to 8 nullable columns.

In MySQL, session->used_tables was being set for mysql_insert in
check_view_single_update. When we removed VIEWs, we didn't fix up this
funny if() condition in mysql_insert (which is not at *all* surprising).
Why is this not surprising? Because having this kind of interdependency is
just total ass and ends up taking days to find something as damn ass subtle
as this. Clear, readable, obvious code FTW.