= Сообщение: 2762 из 3581 ======================================== RU.GOLDED = От : Vitaliy Aksyonov 1:104/117 03 Oct 23 20:33:10 Кому : Semen Panevin 03 Oct 23 20:33:10 Тема : Re: Еще один крэш FGHI : area://RU.GOLDED?msgid=1:104/117+651cd052 На : area://RU.GOLDED?msgid=1:104/117+651c13ae = Кодировка сообщения определена как: CP866 ================================== Ответ: area://RU.GOLDED?msgid=2:5025/121+651d2607 ============================================================================== Привет, Semen!
03 Oct 23 07:14, я писал(а) тебе:
VA>>>> hunspell пытается проверять орфографию, думая, что ему VA>>>> подсунули текст в UTF-8, а там KOI8-R. И ему срывает крышу. SP>>> Интересно... SP>>> Но там же iconv не для перекодировки в коде проверки орфографии SP>>> ли используется как раз? У меня вроде включен.
SP>> Попробовал не сохранять сообщение, а отменить.
VA> Там есть заезд по памяти в одном месте точно. В файле VA> goldlib\gall\gespell.cpp в функции void CSpellLang::RecodeText(const VA> char *srcText, std::string &dstText, bool flag) найди строку char VA> *dstbuffer = new char[srcLen+1]; и сделай буффер побольше, например VA> вот так char *dstbuffer = new char[srcLen * 4 + 1];
VA> При преобразовании однобайтной кодировки в UTF-8 весело портим память. VA> Размер буфера не проверяется.
VA> Еще у меня коряво преобразовывает из KOI8-R в UTF-8. С этим я еще VA> покопаюсь.
Это была адская подстава. :) Оказалось, что таблица перекодировки из koi8-r в uft-8 - это, на самом деле копия таблицы cp866 -> utf-8. Естественно, что после перекодировки получался мусор. Поправил таблицу (отправил pull request) и проверка орфографии с utf-8 словарем завелась. Но все равно с такими словарями это мало практично, ведь эхотаг не умеет преобразовать назад из utf-8 в локальную кодировку. Я все равно поправлю там заезды по памяти, но никому не рекомендую использовать словари в многобайтных кодировках.
VA> А вообще, попробуй ради эксперимента преобразовать свои словари в VA> KOI8-R и попробуй с "родным" hunspell и с твоим патчем. 99%, что VA> взлетит. У меня точно работает.
VA> Для этого достаточно перекодировать .dic и .aff файлы и в .aff файле VA> поменять _SET UTF-8_ на _SET KOI8-R_
VA> Очень интересно, взлетит ли у тебя.
[...skipped...]
SP>> Хотел почитать лог, и обнаружил что лог файл у меня создаётся, но SP>> он всегда пустой. Вообще никаких логов. ЧЯДНТ? В конфиге ничего SP>> про лог левелы не нашёл. Лог формат стоит вроде Fd. Попробовать SP>> другой?
SP>> Что интересно - дальше в коде LoadCharset вроде как нету SP>> использования iconv, проходится по таблицам перекодировки из SP>> конфига, и если не находит там нужную (а utf8 у меня SP>> действительно нету, я как-то на iconv полагался...) то говорит SP>> "не шмогла", current_table = -1 и return 0
Дело в том, что даже если есть iconv, то таблица перекодировки там все равно должна быть. Поддержка iconv очень фрагментарная. Её надо серьезно допиливать, чтобы работало.
SP>> Что происходит дальше - пока некогда разбираться... SP>> Понять бы, почему логи не пишутся...
VA> Логи у меня пишутся. Логлевелов вроде там нет никаких. Хотя я могу VA> быть неправ. Еще на настолкьо глубоко вникал.
VA> Хуже всего то, что некоторый код весело пишет в stdout/stderr и портит VA> картинку.
VA> ЗЫ. Вот и нашел себе следущую задачу. :) Переделать XlatStr, чтобы не VA> было заездов по памяти. Как минимум - передавать размер выходного VA> буфера.
Вот займусь этим пока.
Best regards, Vitaliy Aksyonov.
... В России одна беда - дураки ей дОроги. --- GoldED+/LNX 1.1.5-b20230920 * Origin: Aurora, Colorado (1:104/117)
