Conversation
…aracter set conversion An array element of an odd-size VARCHAR (e.g. VARCHAR(3) in a single-byte character set) can start at an odd address. slice_callback wrote such elements with MOV_make_string, which converts through CVT_move and CommonCallbacks, so the slice was copied without transliteration. Move the value with MOV_move into an aligned temporary instead, as for aligned elements, and copy it.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #9180.
An element of a
VARCHAR(n)array with an odd element size (n + 2bytes for single-bytecharacter sets,
3 * n + 2for UNICODE_FSS) can start at an odd address.slice_callbackwritessuch elements with
MOV_make_string, which converts throughCVT_moveandCommonCallbacks,whose
transliterate()does nothing. So when the slice character set differs from the columnone, every second element is stored without conversion (or rejected with "string right
truncation" when the unconverted bytes don't fit), and UNICODE_FSS columns can get malformed
strings.
The fix moves the value with
MOV_move(engine callbacks, as for aligned elements) into analigned temporary that has the element's descriptor, then copies the length and the text to the
element's address. The reading direction already uses
MOV_movefor unaligned elements and iscorrect.
Tested on debug builds of master and v5.0-release with the reproducer from the issue and with an
extended test: VARCHAR(1), (2), (3), (5) in WIN1251 / ISO8859_1 written from UTF8, a value that
fits only after conversion, 2-dimensional arrays,
blr_varying, UNICODE_FSS VARCHAR(1)/(3)written from WIN1251 and ISO8859_1, UTF8, same character set and NONE columns. The stored bytes
of every element are checked with
cast(COL[i] as varchar(64) character set octets)and withisc_get_slicein both character sets.Please consider a backport to v5.0 (and older branches if applicable): the code is the same
there, and the bug reproduces on 5.0.4, 3.0.14 and 2.5.9. A branch for v5.0-release is ready:
madorin:fix-slice-varying-charset-5.0.