| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Also make input string reference const
<https://github.com/ydb-platform/ydb/issues/12306>
Make input string reference const
Make sure returned TStringBuffers do not change during splitter lifetime
splitter.Consume() возвращает TStringBuf.
Если в колонке есть ескейпинг кавычек, вся колонка обрамлена двойными кавычками (`"`), а внутри для ескейпинга двойных кавычек используются две идущие подряд двойные кавычки (`""`).
В таком случае вернуть TStringBuf, ссылающийся на кусок входящего TString, не получится, т.к. нужной подстроки в нем не существует.
Для этого используется мембер TVector\<TStringbuf\> CustomStrings. В него накидываются нужные кусочки из исходной строки и в конце складываются в мембер-строку TString CustomString
Например, из строки `"abc""cde""efg"` копились кусочки `abc"`, `cde"`, `efg` и в конце склеивались.
И возвращался TStringBuf из этой строки-мембера.
Проблема в том, что если в другой колонке той же строки также встречались кавычки с ескейпингом, эта строка-мембер CustomString очищалась. При том, что на неё всё еще ссылался возвращённый ранее TStringBuf.
В итоге "предыдущий" TStringBuf либо начинал ссылаться на часть новой строки, если новая строка была длиннее, либо на часть новой строки \+ рандомный набор байт в памяти, если новая строка оказывалась короче.
Фикс в том, чтобы хранить все строки, сгенерённые сплиттером, всё время жизни сплиттера
commit_hash:aa4957e1d8030cd48d06eaa16a7ad61e878348f8
|
