| Bug #72715 | character set code endianness dependent on CPU type rather than endianness of CP | ||
|---|---|---|---|
| Submitted: | 21 May 2014 22:39 | Modified: | 22 May 2014 8:00 |
| Reporter: | Stewart Smith | Email Updates: | |
| Status: | Verified | Impact on me: | |
| Category: | MySQL Server: Charsets | Severity: | S3 (Non-critical) |
| Version: | 5.6.17 | OS: | Any |
| Assigned to: | CPU Architecture: | Any | |
[22 May 2014 8:00]
MySQL Verification Team
Hello Stewart, Thank you for the bug report. Thanks, Umesh
Description: The PowerLinux Migration Toolkit helped find this gem in include/m_ctype.h /* On i386 we store Unicode->CS conversion tables for some character sets using Big-endian order, to copy two bytes at onces. This gives some performance improvement. */ #ifdef __i386__ #define MB2(x) (((x) >> 8) + (((x) & 0xFF) << 8)) #define MY_PUT_MB2(s, code) { *((uint16*)(s))= (code); } #else #define MB2(x) (x) #define MY_PUT_MB2(s, code) { (s)[0]= code >> 8; (s)[1]= code & 0xFF; } #endif Which needs some analysis as to the validity on both non-x86 and especially on POWER BE and LE (maybe also MIPS/MIPSel). How to repeat: Code analysis. Suggested fix: think carefully.. hopefully I'll investigate further and provide further insight/a patch... but if somebody else gets to it first, yay! I'm mostly filing the bug to keep track of this issue.