You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Make sure returned TStringBuffers do not change during splitter lifetime. Also make input string reference const
<#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
0 commit comments