Fix for BUG#51716 and BUG#51787.

In BUG#51787 we were using the wrong charset to print out the
data. We were using the field charset for the string that would
hold the information. This caused the assertion, because the
string length was not aligned with UTF32 bytes requirements for
storage.

We fix this by using &my_charset_latin1 in the string object
instead of the field->charset(). As a side-effect, we needed to
extend the show_sql_type interface so that it took the field
charset is now passed as a parameter, so that one is able to
calculate the correct field size.

In BUG#51716 we had issues with Field_string::pack and
Field_string::unpack. When packing, the length was incorrectly
calculated. When unpacking, the padding the string would be
padded with the wrong bytes (a few bytes less than it should).

We fix this by resorting to charset abstractions (functions) that
calculate the correct length when packing and pad correctly the
string when unpacking.

2 files changed, 110 insertions, 0 deletions

diff --git a/mysql-test/suite/rpl/r/rpl_row_charset.result b/mysql-test/suite/rpl/r/rpl_row_charset.result
new file mode 100644
index 00000000000..b7ef02b93bb
--- /dev/null
+++ b/mysql-test/suite/rpl/r/rpl_row_charset.result
@@ -0,0 +1,42 @@
+stop slave;
+drop table if exists t1,t2,t3,t4,t5,t6,t7,t8,t9;
+reset master;
+reset slave;
+drop table if exists t1,t2,t3,t4,t5,t6,t7,t8,t9;
+start slave;
+SET SQL_LOG_BIN=0;
+CREATE TABLE t1 (c1 char(255) DEFAULT NULL, KEY c1 (c1)) DEFAULT CHARSET=utf32;
+Warnings:
+Warning	1071	Specified key was too long; max key length is 1000 bytes
+SET SQL_LOG_BIN=1;
+SET @saved_slave_type_conversions= @@global.slave_type_conversions;
+include/stop_slave.inc
+SET GLOBAL SLAVE_TYPE_CONVERSIONS='ALL_NON_LOSSY';
+include/start_slave.inc
+SET SQL_LOG_BIN=0;
+CREATE TABLE t1 ( c1 varchar(255) DEFAULT NULL, KEY c1 (c1)) DEFAULT CHARSET=utf32;
+Warnings:
+Warning	1071	Specified key was too long; max key length is 1000 bytes
+SET SQL_LOG_BIN=1;
+INSERT INTO t1(c1) VALUES ('insert into t1');
+DROP TABLE t1;
+SET GLOBAL SLAVE_TYPE_CONVERSIONS= @saved_slave_type_conversions;
+include/stop_slave.inc
+include/start_slave.inc
+CREATE TABLE t1(c1 CHAR(10) CHARACTER SET utf16 DEFAULT 'ola');
+INSERT INTO t1 VALUES ('abc');
+INSERT INTO t1 VALUES ();
+#### ON MASTER
+SELECT c1, hex(c1) from t1; ;
+c1	abc
+hex(c1)	006100620063
+c1	ola
+hex(c1)	006F006C0061
+#### ON SLAVE
+SELECT c1, hex(c1) FROM t1; ;
+c1	abc
+hex(c1)	006100620063
+c1	ola
+hex(c1)	006F006C0061
+Comparing tables master:test.t1 and slave:test.t1
+DROP TABLE t1;
diff --git a/mysql-test/suite/rpl/t/rpl_row_charset.test b/mysql-test/suite/rpl/t/rpl_row_charset.test
new file mode 100644
index 00000000000..b5108541b6f
--- /dev/null
+++ b/mysql-test/suite/rpl/t/rpl_row_charset.test
@@ -0,0 +1,68 @@
+-- source include/master-slave.inc
+-- source include/have_binlog_format_row.inc
+
+#
+# BUG#51787 Assertion `(n % 4) == 0' on slave upon INSERT into a table with UTF32
+#
+
+SET SQL_LOG_BIN=0;
+CREATE TABLE t1 (c1 char(255) DEFAULT NULL, KEY c1 (c1)) DEFAULT CHARSET=utf32;
+SET SQL_LOG_BIN=1;
+
+-- connection slave
+
+-- let $reset_slave_type_conversions= 0
+
+SET @saved_slave_type_conversions= @@global.slave_type_conversions;
+
+#
+#  Force test to cover conversion execution path in the
+#  slave, which also makes use of sql_type method, thence
+#  can ultimately trigger the assertion.
+#
+-- source include/stop_slave.inc
+SET GLOBAL SLAVE_TYPE_CONVERSIONS='ALL_NON_LOSSY';
+-- source include/start_slave.inc
+
+SET SQL_LOG_BIN=0;
+CREATE TABLE t1 ( c1 varchar(255) DEFAULT NULL, KEY c1 (c1)) DEFAULT CHARSET=utf32;
+SET SQL_LOG_BIN=1;
+
+-- connection master
+
+INSERT INTO t1(c1) VALUES ('insert into t1');
+DROP TABLE t1;
+
+--sync_slave_with_master
+
+# assertion: the slave woul hit an/several assertions:
+#            before and during slave conversion procedure
+#            Now that is fixed, it wont.
+
+SET GLOBAL SLAVE_TYPE_CONVERSIONS= @saved_slave_type_conversions;
+-- source include/stop_slave.inc
+-- source include/start_slave.inc
+-- connection master
+
+#
+# BUG#51716: Char column with utf16 character set gives wrong padding on slave
+#
+
+CREATE TABLE t1(c1 CHAR(10) CHARACTER SET utf16 DEFAULT 'ola');
+INSERT INTO t1 VALUES ('abc');  # explicit value is inserted and encoded correctly
+INSERT INTO t1 VALUES ();       # default value is inserted and encoded correctly
+
+-- echo #### ON MASTER
+--query_vertical SELECT c1, hex(c1) from t1; 
+
+-- sync_slave_with_master
+
+-- echo #### ON SLAVE
+--query_vertical SELECT c1, hex(c1) FROM t1; 
+
+# assertion: tables don't differ
+-- let $diff_table_1=master:test.t1
+-- let $diff_table_2=slave:test.t1
+-- source include/diff_tables.inc
+
+DROP TABLE t1;