Bug #38701: Crash in String::append when inserting duplicate empty strings an uft8

SET col
                  
When reporting a duplicate key error the server was making incorrect assumptions 
on what the state of the value string to include in the error is.

Fixed by accessing the data in this string in a "safe" way (without relying on it
having a terminating 0).
      
Detected by code analysis and fixed a similar problem in reporting the foreign key
duplicate errors.

mysql-test/r/type_set.result:
  Bug #38701: test case
mysql-test/t/type_set.test:
  Bug #38701: test case
sql/handler.cc:
  Bug #38701: don't rely on the presence of a terminating 0 in the string

1 files changed, 2 insertions, 2 deletions

diff --git a/sql/handler.cc b/sql/handler.cc
index cc2db397ad4..f26e84bdfdf 100644
--- a/sql/handler.cc
+++ b/sql/handler.cc
@@ -2496,7 +2496,7 @@ void handler::print_keydup_error(uint key_nr, const char *msg)
       str.append(STRING_WITH_LEN("..."));
     }
     my_printf_error(ER_DUP_ENTRY, msg,
-		    MYF(0), str.c_ptr(), table->key_info[key_nr].name);
+		    MYF(0), str.c_ptr_safe(), table->key_info[key_nr].name);
   }
 }
 
@@ -2564,7 +2564,7 @@ void handler::print_error(int error, myf errflag)
         str.append(STRING_WITH_LEN("..."));
       }
       my_error(ER_FOREIGN_DUPLICATE_KEY, MYF(0), table_share->table_name.str,
-        str.c_ptr(), key_nr+1);
+        str.c_ptr_safe(), key_nr+1);
       DBUG_VOID_RETURN;
     }
     textno= ER_DUP_KEY;