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: | |
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
[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.