= Сообщение: 2906 из 3580 ======================================== RU.GOLDED =
От : Vitaliy Aksyonov 1:104/117 23 Oct 23 17:59:54
Кому : Nil A 23 Oct 23 17:59:54
Тема : Re: Широкие терминалы и char buf[сколько не жалко].. StyleCodeHighlight
FGHI : area://RU.GOLDED?msgid=1:104/117+65370da3
На : area://RU.GOLDED?msgid=2:5015/46+65341203
= Кодировка сообщения определена как: CP866 ==================================
Ответ: area://RU.GOLDED?msgid=2:5015/46+65371724
==============================================================================
Привет, Nil!
21 Oct 23 20:49, ты писал(а) мне:
NA>> Всё-таки хер ты так просто починишь эти широкие терминалы в
NA>> эхотаге. 80x25 форева!
NA>> Например, ты заменил все эти
NA>> - char buf[256], tmp[256];
NA>> + char buf[MAXCOL], tmp[MAXCOL];
NA>> А фиг там, там разных char buf[200] разбросано по коду
NA>> (Container::StyleCodeHighlight). И наступить на них можно, если
NA>> там в письмах какие-то особо длнные _такие вот_, *или вот такое*
NA>> какие-то выделения, только за пределами этимх 256 байтов обычно.
Понимаешь, самая большая проблема, что их нельзя просто Find/Replace/sed. Во многих местах буферы адекватного размера, так как есть натуральные ограничения данных. Например, имя сисопа в пакете. Плюс эти структуры копируются простым memcpy, а некоторые даже используются! для "сериализации". Так что там переделок намного больше, чем хотелось бы.
NA>> Или вот, подсвечиваем УРЛы как-то по-разному, и там этот буфер на
NA>> 200.
NA> Короче, вот фикс, чтобы на широком экране, на длинной строчке, где
NA> есть *какие-то выделения* голдед не падал.
Создал pull request от твоего имени. :)
Там дело хуже. Когда URL длиннее строки, то подсвечивается только первая строка. И это не айс. И я не вижу нормального способа это починить. Ведь с новой строки может быть как продолжение ссылки, так и просто текст.
Далее. Список схем, которые понимает эхотаг, там жестко зашит. А по-хорошему, его надо просто парсить и искать URI.
В педивикии описано довольно неплохо:
https://en.wikipedia.org/wiki/Uniform_Resource_Identifier
А список возможных схем вообще впечатляет:
https://en.wikipedia.org/wiki/List_of_URI_schemes
А теперь добавляем туда юникодные символы, и получаем еще более интересную картину.
Какой-нибудь https://пиво.рф или git@исходники.ру:мой/репозиторий.git
Кто там хотел юникод? :)
[...skipped...]
NA> И с этим фиксом я могу зайти на сообщение, на котором раньше валилось.
NA> А потом я нажал сохранить в файл, и..... угадай что?
NA> golded3/getpls.cpp: TemplateToText()
NA> char quotestr[100];
NA> char qbuf[100];
Там ещё другое есть. Это overlap при копировании строк. Когда oldMsg и msg - это тот же объект. :) Вообще весело.
NA> Вот теперь в них падает. Их что теперь, все в CREATEBUFFER(char, buf,
NA> MAXCOL) ?
Нет. Нельзя бездумно все. Лучше потихоньку переводить на std::string (в котором, кстати, тот же UTF-8 прекрасно хранится, если не надо делать посимвольных операций, конечно), меняя алгоритмы.
NA> P.S. Я думал, сколько нужно мест вычистить в голдеде
>> $ grep -rI strcpy | wc -l
>> 957
NA> Ну и заодно
>> $ grep -rI sprintf | wc -l
>> 587
NA> Но, на самом деле всё зло там вот в таких вот магических цифрах 100,
NA> 128, 200, 256,... размера буфера на стеке, которого должно хватить.
>> $ grep -rI '\[100\]\|\[128\]\|\[200\]\|\[256\]' | wc -l
>> 222
Все зло не в этом, а в том, что копируют без проверки размера. Пусть strcpy и опасная функция, но даже её можно использовать разумно. Даже на ассемблере пишут код и ничего, работает и не взрывается.
Best regards,
Vitaliy Aksyonov.
... Я сегодня бодр и весел: утром рэпера повесил.
--- GoldED+/LNX 1.1.5-b20231021
* Origin: Aurora, Colorado (1:104/117)
|
