Bug #26983 create_field->pack_length not initialized?
Submitted: 9 Mar 2007 1:33 Modified: 6 Apr 2007 14:20
Reporter: Chongfeng Hu Email Updates:
Status: Not a Bug Impact on me:
Category:MySQL Server: General Severity:S3 (Non-critical)
Version:5.1-falcon-BK, 5.2.0 falcon-alpha OS:Any (any)
Assigned to: Georgi Kodinov CPU Architecture:Any
Tags: create_field, LENGTH, pack_length

[9 Mar 2007 1:33] Chongfeng Hu
In file sql/field.cc, in function void create_field::init_for_tmp_table(...), I saw the following piece of code:

  field_name= "";
  sql_type= sql_type_arg;
  char_length= length= length_arg;;
  unireg_check= Field::NONE;
  interval= 0;

pack_length is not initialized here. As far as I know, pack_length is length plus some header overhead. If length is inited here, why not pack_length as well?

How to repeat:
I found this one with the help of a code-checking tool.
[29 Mar 2007 7:31] Valeriy Kravchuk
Thank you for a problem report. Verified with code rerview on latest 5.1-falcon-BK sources. Code is still the same as reportered.
[6 Apr 2007 14:20] Georgi Kodinov
Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://dev.mysql.com/doc/ and the instructions on
how to report a bug at http://bugs.mysql.com/how-to-report.php

pack_length is not initialized here simply because it's not used. The only context where init_for_tmp_table is called is Item_sum_distinct::setup().
The resulting create_field instance is then fed into make_field() through create_virtual_tmp_table(). And make_field() doesn't use create_field::pack_length. 
It's mysql's best practice not to (over-)initialize data out of the context where they get their real value so subsequent runs through code analysis tools (like valgrind) would show an error when unitialized variables are used.