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
Portions of this website are copyright © 2001, 2002 The PHP Group
Page generated in 0.049 sec. using MySQL 8.4.7-u6-cloud
Timestamp references displayed by the system are UTC.
Content reproduced on this site is the property of the
respective copyright holders.
It is not reviewed in advance
by Oracle and does not necessarily represent the opinion of
Oracle or any other party.
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.