Bug #86408 Possible unintended usage of "start_pos" variable
Submitted: 22 May 2017 15:09 Modified: 23 May 2017 13:32
Reporter: Petru-Florin Mihancea Email Updates:
Status: Not a Bug Impact on me:
None 
Category:MySQL Server: MyISAM storage engine Severity:S3 (Non-critical)
Version:5.7 OS:Any
Assigned to: CPU Architecture:Any

[22 May 2017 15:09] Petru-Florin Mihancea
Description:
Hi,

While experimenting with a CodeSonar plugin we develop, we noticed a potential bug in file "mysql-server/storage/myisam/myisampack.c" line 2728 and 2729:

bindigits(tree->code[(uchar) *start_pos],
    (uint)tree->code_len[(uchar) *start_pos])));

As indexes for tree->code and tree->code_len, shouldn't you use the blob variable (instead of start_pos)?

Thank you.

How to repeat:
This is a bug observed at the source code level.
[22 May 2017 16:09] MySQL Verification Team
Hi!

Actually, no. Variable 'start_pos' is positioned exactly where it should be, immediately before the big

switch (...) 
{
  ......
}

statement.

Please, let us know if you have run into any significant problems.

Do also note that the table obtained by myisampack can be used only as READ-ONLY table. If you write anything into it, it will be totally corrupted.
[22 May 2017 16:30] Petru-Florin Mihancea
Maybe more context is needed. These are lines 2724 to 2729.

 DBUG_PRINT("fields",
            ("value: 0x%02x  code: 0x%s  bits: %2u  bin: %s",
              (uchar) *blob, hexdigits(tree->code[(uchar) *blob]),
              (uint) tree->code_len[(uchar) *blob],
              bindigits(tree->code[(uchar) *start_pos], //2728
                        (uint)tree->code_len[(uchar) *start_pos]))); //2729

My sensation was that the intention is to "DBUG_PRINT" the blob values in hex and the same value in binary. While blob is printed in hex, in binary start_pos is printed. It looks weird if the intention of the code is the one I mentioned (print values in hex and in binary form) :). Or?
[23 May 2017 13:32] MySQL Verification Team
No.

start_pos is positioned in such a manner that it points to the  metadata that are required in order to fetch the column properly.

Not a bug.