Широкие терминалы и char buf[сколько не жалко].. StyleCodeНighlight()

Nil A написал(а) к All в Oct 23 05:14:04 по местному времени:

Нello, All!

Всё-таки хер ты так просто починишь эти широкие терминалы в эхотаге. 80x25 форева!

Например, ты заменил все эти
- char buf[256], tmp[256];
+ char buf[MAXCOL], tmp[MAXCOL];

А фиг там, там разных char buf[200] разбросано по коду (Container::StyleCodeНighlight).
И наступить на них можно, если там в письмах какие-то особо длнные такие вот, или вот такое какие-то выделения, только за пределами этимх 256 байтов обычно.

Или вот, подсвечиваем УРЛы как-то по-разному, и там этот буфер на 200.
ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7f27fb6efef8 at pc 0x7f2800cb9dcb bp 0x7fff678891f0 sp 0x7fff678889a0
WRITE of size 252 at 0x7f27fb6efef8 thread T0
#0 0x7f2800cb9dca in _interceptor_strncpy ../../../../src/libsanitizer/asan/asaninterceptors.cc:476
#1 0xafb4f7 in strxcpy(char, char const, unsigned long) /home/fido/src/golded-plus/goldlib/gall/gstrutil.cpp:725
#2 0x594164 in Container::StyleCodeНighlight(char const*, int, int, bool, int) /home/fido/src/golded-plus/golded3/gectnr.cpp:209
#3 0x86faa2 in GMsgBodyView::PaintLine(int, Line*) /home/fido/src/golded-plus/golded3/geview.cpp:527
#4 0x8708f6 in GMsgBodyView::Paint() /home/fido/src/golded-plus/golded3/geview.cpp:547
#5 0x7b88cf in Reader() /home/fido/src/golded-plus/golded3/geread.cpp:416
#6 0x6c63bb in main /home/fido/src/golded-plus/golded3/gemain.cpp:54
#7 0x7f27ff349f44 in _libc_start_main (/lib/x8664-linux-gnu/libc.so.6+0x21f44)
#8 0x407c98 (/home/fido/src/golded-plus/build_asan/golded3/golded+0x407c98)

Address 0x7f27fb6efef8 is located in stack of thread T0 at offset 248 in frame
#0 0x592a35 in Container::StyleCodeНighlight(char const*, int, int, bool, int) /home/fido/src/golded-plus/golded3/gectnr.cpp:94

Best Regards, Nil
--- GoldED+/LNX 1.1.5

Nil A написал(а) к Vitaliy Aksyonov в Oct 23 20:49:36 по местному времени:

Нello, Nil!

Tuesday October 17 2023 05:14, from Nil A -> All:

NA> Всё-таки хер ты так просто починишь эти широкие терминалы в эхотаге.
NA> 80x25 форева!

NA> Например, ты заменил все эти
NA> - char buf[256], tmp[256];
NA> + char buf[MAXCOL], tmp[MAXCOL];

NA> А фиг там, там разных char buf[200] разбросано по коду
NA> (Container::StyleCodeНighlight). И наступить на них можно, если там в
NA> письмах какие-то особо длнные такие вот, или вот такое какие-то
NA> выделения, только за пределами этимх 256 байтов обычно.

NA> Или вот, подсвечиваем УРЛы как-то по-разному, и там этот буфер на 200.

Короче, вот фикс, чтобы на широком экране, на длинной строчке, где есть какие-то выделения голдед не падал.

diff --git a/golded3/gectnr.cpp b/golded3/gectnr.cpp
--- a/golded3/gectnr.cpp
+++ b/golded3/gectnr.cpp
@@ -95,7 +95,7 @@ void Container::StyleCodeНighlight(const char* text, int row, int col, bool dohi

uint sclen = 0;
const char* txptr = text;
- char buf[200];
+ CREATEBUFFER(char, buf, MAXCOL);
const char* ptr = text;
const char* stylemargins = " -|\\"; // we probably have to make a keyword for it
char* punctchars = CFG->stylecodepunct;

И с этим фиксом я могу зайти на сообщение, на котором раньше валилось. А потом я нажал сохранить в файл, и..... угадай что?

golded3/getpls.cpp: TemplateToText()
char quotestr[100];
char qbuf[100];

Вот теперь в них падает. Их что теперь, все в CREATEBUFFER(char, buf, MAXCOL) ?

P.S. Я думал, сколько нужно мест вычистить в голдеде
> $ grep -rI strcpy | wc -l
> 957
Ну и заодно
> $ grep -rI sprintf | wc -l
> 587
Но, на самом деле всё зло там вот в таких вот магических цифрах 100, 128, 200, 256,... размера буфера на стеке, которого должно хватить.
> $ grep -rI '\[100\]\|\[128\]\|\[200\]\|\[256\]' | wc -l
> 222

Best Regards, Nil
--- GoldED+/LNX 1.1.5

Vitaliy Aksyonov написал(а) к Nil A в Oct 23 17:59:54 по местному времени:

Привет, 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::StyleCodeНighlight). И наступить на них можно, если
NA>> там в письмах какие-то особо длнные такие вот, или вот такое
NA>> какие-то выделения, только за пределами этимх 256 байтов обычно.

Понимаешь, самая большая проблема, что их нельзя просто Find/Replace/sed. Во многих местах буферы адекватного размера, так как есть натуральные ограничения данных. Например, имя сисопа в пакете. Плюс эти структуры копируются простым memcpy, а некоторые даже используются! для "сериализации". Так что там переделок намного больше, чем хотелось бы.

NA>> Или вот, подсвечиваем УРЛы как-то по-разному, и там этот буфер на
NA>> 200.

NA> Короче, вот фикс, чтобы на широком экране, на длинной строчке, где
NA> есть какие-то выделения голдед не падал.

Создал pull request от твоего имени. :)

Там дело хуже. Когда URL длиннее строки, то подсвечивается только первая строка. И это не айс. И я не вижу нормального способа это починить. Ведь с новой строки может быть как продолжение ссылки, так и просто текст.

Далее. Список схем, которые понимает эхотаг, там жестко зашит. А по-хорошему, его надо просто парсить и искать URI.
В педивикии описано довольно неплохо:
https://en.wikipedia.org/wiki/Unifor...</b>Identifier

А список возможных схем вообще впечатляет:
https://en.wikipedia.org/wiki/Listof_URIschemes

А теперь добавляем туда юникодные символы, и получаем еще более интересную картину.
Какой-нибудь 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

Nil A написал(а) к Vitaliy Aksyonov в Oct 23 03:37:00 по местному времени:

Нello, Vitaliy!

Monday October 23 2023 17:59, from Vitaliy Aksyonov -> Nil A:

NA>>> А фиг там, там разных char buf[200] разбросано по коду
NA>>> (Container::StyleCodeНighlight). И наступить на них можно, если
NA>>> там в письмах какие-то особо длнные такие вот, или вот такое
NA>>> какие-то выделения, только за пределами этимх 256 байтов обычно.

VA> Понимаешь, самая большая проблема, что их нельзя просто
VA> Find/Replace/sed. Во многих местах буферы адекватного размера, так как
VA> есть натуральные ограничения данных. Например, имя сисопа в пакете.
VA> Плюс эти структуры копируются простым memcpy, а некоторые даже
VA> используются! для "сериализации". Так что там переделок намного
VA> больше, чем хотелось бы.

Семён Семёныч, если бы там sed'ом можно было бы, то яб уже сделал ;-)

NA>> Короче, вот фикс, чтобы на широком экране, на длинной строчке,
NA>> где есть какие-то выделения голдед не падал.
VA> Создал pull request от твоего имени. :)

Спасиба.

VA> Там дело хуже. Когда URL длиннее строки, то подсвечивается только
VA> первая строка. И это не айс. И я не вижу нормального способа это
VA> починить. Ведь с новой строки может быть как продолжение ссылки, так и
VA> просто текст.

Там в деде есть много каких-то интернетовских делов, которые мне ниразу не понятны кстати.
То, якобы емейлы он умеет читать писать, только по smtp/pop3 не ходит, хотя не проверял.
То URLы парсит как не в себя, но зачем? Вроде какие-то виндовые голдеды позволяют тыкать мышью в ссылки, и откроется в браузере, но я могу гнать.

VA> Далее. Список схем, которые понимает эхотаг, там жестко зашит.

[GoldED-NSF](https://fido.g0x.ru/golded/index.php) умеет и не только RFC схемы, но и area:// схемы.
Кстати, ты глянул на патч, его можно влить в наш меинстрим-голдед?

VA> А теперь добавляем туда юникодные символы, и получаем еще более
VA> интересную картину. Какой-нибудь https://пиво.рф или
VA> git@исходники.ру:мой/репозиторий.git
VA> Кто там хотел юникод? :)

Ага, давай уникод, майм, урл, всё в одну кучу смешаем.

VA> Там ещё другое есть. Это overlap при копировании строк. Когда oldMsg и
VA> msg - это тот же объект. :) Вообще весело.

На собеседовании надо спрашивать потому что, чем отличается memcpy от memmove. Хотя в голдеде всё через strcpy, который во всех современных компилятора в buildin превращается по-любому, а не в либси ходит.

NA>> Вот теперь в них падает. Их что теперь, все в CREATEBUFFER(char,
NA>> buf, MAXCOL) ?
VA> Нет. Нельзя бездумно все. Лучше потихоньку переводить на std::string

-std=c++11 минимум только включите сначала, чтобы lvalue понимали, и move случался где надо, без копирований, и разные RVO и NRVO случались (хотя они и так случаются в современном компиляторе, даже со старыми стандартами, ибо никто не запрещает же).
-std=c++17 яб на минималке включил, и общался там не через const std::string& везде, если ты уж будешь заменять, а на std::string_view.

VA> (в котором, кстати, тот же UTF-8 прекрасно хранится, если не надо
VA> делать посимвольных операций, конечно), меняя алгоритмы.

В том то и дело, что std::string хранит просто байты, и ему пофиг что там, он такой же std::vector почти.
Для нужд редактора нужно знать.. я щас не буду про поддержку еврита справо-налево и потом тут же английский и русский, справа налево, или какие-то азиатские языки, где вниз пишут..
Для нужд редактора нужно знать сколько графем..да блин, опять не смогу объяснить на пальцах.. и как минимум надо нормализовывать эти акценты, а то код сразу с акцентом, или буква А и к ней палочка с боку другим юникод символом, который не занимает знакоместо.

Такшта, не углубляясь в дебри, рекомендую не std::string, а какой-нибудь icu::UnicodeString.
Ну окей, icu - это оверкилл, можно договориться, что в std::string мы ложим только utf8. Но тогда к нему надо функции посчитать сколько это символов в строке. Ну и тогда iconv сюда тупо зафигачить, и конвертить всё в utf8, а обратно с флажком //TRANSLIT.

Best Regards, Nil
--- GoldED+/LNX 1.1.5

Vitaliy Aksyonov написал(а) к Nil A в Oct 23 09:40:32 по местному времени:

Привет, Nil!

24 Oct 23 03:37, ты писал(а) мне:

VA>> Там дело хуже. Когда URL длиннее строки, то подсвечивается только
VA>> первая строка. И это не айс. И я не вижу нормального способа это
VA>> починить. Ведь с новой строки может быть как продолжение ссылки,
VA>> так и просто текст.
NA> Там в деде есть много каких-то интернетовских делов, которые мне
NA> ниразу не понятны кстати. То, якобы емейлы он умеет читать писать,
NA> только по smtp/pop3 не ходит, хотя не проверял. То URLы парсит как не
NA> в себя, но зачем? Вроде какие-то виндовые голдеды позволяют тыкать
NA> мышью в ссылки, и откроется в браузере, но я могу гнать.

Парсит, так как можно настроить обработчик URL и открывать браузер прямо из деда. Ты, например, можешь открыть lynx.

VA>> Далее. Список схем, которые понимает эхотаг, там жестко зашит.

NA> [GoldED-NSF](https://fido.g0x.ru/golded/index.php) умеет и не только
NA> RFC схемы, но и area:// схемы. Кстати, ты глянул на патч, его можно
NA> влить в наш меинстрим-голдед?

Смотрел на него и даже почти влил. Но код там не самый красивый. Они прикрутили это сбоку, хотя никто не мешал встроить в существующую инфраструктуру. Если это реально кому-то нужно, то лучше просто взять их код за основу, но переделать красивее.

VA>> Там ещё другое есть. Это overlap при копировании строк. Когда
VA>> oldMsg и msg - это тот же объект. :) Вообще весело.
NA> На собеседовании надо спрашивать потому что, чем отличается memcpy от
NA> memmove. Хотя в голдеде всё через strcpy, который во всех современных
NA> компилятора в buildin превращается по-любому, а не в либси ходит.

Если тебя такое спрашивают на собеседовании, то стоит задуматься, хочешь ли ты там работать. :) В современном C++ эти функции не используются. Что не отменяет того, что разбираться в таком не помешает. А вообще - это скилл чтения манов. Там чёрным по белому написано, какое поведение у функции.

NA>>> Вот теперь в них падает. Их что теперь, все в CREATEBUFFER(char,
NA>>> buf, MAXCOL) ?
VA>> Нет. Нельзя бездумно все. Лучше потихоньку переводить на
VA>> std::string
NA> -std=c++11 минимум только включите сначала, чтобы lvalue понимали, и
NA> move случался где надо, без копирований, и разные RVO и NRVO случались
NA> (хотя они и так случаются в современном компиляторе, даже со старыми
NA> стандартами, ибо никто не запрещает же). -std=c++17 яб на минималке
NA> включил, и общался там не через const std::string& везде, если ты уж
NA> будешь заменять, а на std::string_view.

Ты опять спутал lvalue и rvalue. И насколько я помню, гарантированный copy elision появился только в C++17. А вот мув может помочь в некоторых местах.

VA>> (в котором, кстати, тот же UTF-8 прекрасно хранится, если не надо
VA>> делать посимвольных операций, конечно), меняя алгоритмы.
NA> В том то и дело, что std::string хранит просто байты, и ему пофиг что
NA> там, он такой же std::vector почти. Для нужд редактора нужно знать.. я
NA> щас не буду про поддержку еврита справо-налево и потом тут же
NA> английский и русский, справа налево, или какие-то азиатские языки, где
NA> вниз пишут.. Для нужд редактора нужно знать сколько графем..да блин,
NA> опять не смогу объяснить на пальцах.. и как минимум надо
NA> нормализовывать эти акценты, а то код сразу с акцентом, или буква А и
NA> к ней палочка с боку другим юникод символом, который не занимает
NA> знакоместо.

NA> Такшта, не углубляясь в дебри, рекомендую не std::string, а
NA> какой-нибудь icu::UnicodeString. Ну окей, icu - это оверкилл, можно
NA> договориться, что в std::string мы ложим только utf8. Но тогда к нему
NA> надо функции посчитать сколько это символов в строке. Ну и тогда iconv
NA> сюда тупо зафигачить, и конвертить всё в utf8, а обратно с флажком
NA> //TRANSLIT.

Для всяких шаблонов и прочего придётся сильно переделывать код. Ведь там часто идут проходы посимвольно. С utf-8 работать такое не будет. Короче, переход на юникод - это огромный проект. И там много о чем надо задуматься.

Для начала хочу сделать адекватное использование iconv. Но там есть свои подводные камни. Например, всякие escape последовательности и обработка нашей замечательной Н. :)

В общем, не все сразу. Не гоните коней, поручик.

Best regards,
Vitaliy Aksyonov.

... Спасение рядового Райана от прапорщика Пилипчука.
--- GoldED+/LNX 1.1.5-b20231021

Nil A написал(а) к Vitaliy Aksyonov в Oct 23 04:59:16 по местному времени:

Нello, Vitaliy!

Tuesday October 24 2023 09:40, from Vitaliy Aksyonov -> Nil A:

NA>> [GoldED-NSF](https://fido.g0x.ru/golded/index.php) умеет и не
NA>> только RFC схемы, но и area:// схемы. Кстати, ты глянул на патч,
NA>> его можно влить в наш меинстрим-голдед?

VA> Смотрел на него и даже почти влил. Но код там не самый красивый. Они
VA> прикрутили это сбоку, хотя никто не мешал встроить в существующую
VA> инфраструктуру. Если это реально кому-то нужно, то лучше просто взять
VA> их код за основу, но переделать красивее.

Придумано не мной? Переделывать с нуля NSF ты не возьмёшься, слишком работы много.

GoldED-NSF сборку пихали в разные кубики и/или фидоайпи, если мне память не изменяет. Значитссс, обкатался тот патч немного. Хотя.

Что они смогли извлечь из этиго area:// я пока не могу понять. Хотя, там шаблоны переделали, что "Nil A -> Vitaliy Aksyonov, in URL @OFGНIUrl:" случается, и там этот @OFGНIUrl раскрыается во что-то. И, грубо говоря, можно туда перейти, а не по слинкованным сообщениям.
Хотя. Идея аффтора, имя которого произносить нельзя, была в том, что по этому OFGНIUrl можно сходить в IPFS (InterPlanetary File System).

Best Regards, Nil
--- GoldED+/LNX 1.1.5

Vitaliy Aksyonov написал(а) к Nil A в Oct 23 07:06:20 по местному времени:

Привет, Nil!

25 Oct 23 04:59, ты писал(а) мне:

NA>>> [GoldED-NSF](https://fido.g0x.ru/golded/index.php) умеет и не
NA>>> только RFC схемы, но и area:// схемы. Кстати, ты глянул на патч,
NA>>> его можно влить в наш меинстрим-голдед?

VA>> Смотрел на него и даже почти влил. Но код там не самый красивый.
VA>> Они прикрутили это сбоку, хотя никто не мешал встроить в
VA>> существующую инфраструктуру. Если это реально кому-то нужно, то
VA>> лучше просто взять их код за основу, но переделать красивее.

NA> Придумано не мной? Переделывать с нуля NSF ты не возьмёшься, слишком
NA> работы много.

Нет. Дело не в том, чтобы "все переписать". Там сбоку прикручено то, что можно добавить в стандартную обработку URL-ов. И, кстати, этот патч не такой большой. Там работы на неделю, если не спешить.

NA> GoldED-NSF сборку пихали в разные кубики и/или фидоайпи, если мне
NA> память не изменяет. Значитссс, обкатался тот патч немного. Хотя.

Он работает, никто не спорит. Но сделать можно иначе. Тут другой вопрос, а нужно ли оно вообще кому-то?

NA> Что они смогли извлечь из этиго area:// я пока не могу понять. Хотя,
NA> там шаблоны переделали, что "Nil A -> Vitaliy Aksyonov, in URL
NA> @OFGНIUrl:" случается, и там этот @OFGНIUrl раскрыается во что-то. И,
NA> грубо говоря, можно туда перейти, а не по слинкованным
NA> сообщениям. Хотя. Идея аффтора, имя которого произносить нельзя, была
NA> в том, что по этому OFGНIUrl можно сходить в IPFS (InterPlanetary File
NA> System).

Вот ты и сам не знаешь, нужна ли эта функциональность вообще.

Best regards,
Vitaliy Aksyonov.

... Гласность это правда, умноженная на безнаказанность.
--- GoldED+/LNX 1.1.5-b20231021

Dmitriy Kulikov написал(а) к Vitaliy Aksyonov в Oct 23 13:20:38 по местному времени:

Мир дому твоему, Vitaliy !

25 Окт 23 07:06, you wrote to Nil A:

NA>> GoldED-NSF сборку пихали в разные кубики и/или фидоайпи, если мне
NA>> память не изменяет. Значитссс, обкатался тот патч немного. Хотя.
VA> Он работает, никто не спорит. Но сделать можно иначе. Тут другой
VA> вопрос, а нужно ли оно вообще кому-то?

Было бы удобно, кстати. Например, когда кто-то кидает в эху ссылку на сообщение в другой эхе и по этой ссылке можно перейти сразу на сообщение. Тогда, было бы неплохо, если бы golded умел эти ссылки создавать по нажатии на какую-нибудь клавишу...

Дмитрий Ю. Куликов
для эхоконференции Редактоp cообщений GoldED [26 Окт 23 - 13:16]
... https://vk.com/hakudzero Telegram: @hakudzero ..
--- GoldED+/W64-MSVC 1.1.5-b20231021 (WinNT 6.2.9200 iF6M12)

Dima Krylov написал(а) к Dmitriy Kulikov в Oct 23 09:31:06 по местному времени:

оПХвЕР!

Kaк-тo нa дняx (26 окт 23) Dmitriy Kulikov пишeт к Vitaliy Aksyonov...

[ ... ]

DK> сообщение. Тогда, было бы неплохо, если бы golded умел эти ссылки
DK> создавать по нажатии на какую-нибудь клавишу...
Ты сейчас так Мицгола воскресишь. ;-)



--- GoldED-NSF

Cheslav Osanadze написал(а) к Dmitriy Kulikov в Oct 23 09:12:12 по местному времени:

Привет Dmitriy!

26 Окт 23 13:20, Dmitriy Kulikov -> Vitaliy Aksyonov:

NA>>> GoldED-NSF сборку пихали в разные кубики и/или фидоайпи, если
NA>>> мне память не изменяет. Значитссс, обкатался тот патч немного.
NA>>> Хотя.
VA>> Он работает, никто не спорит. Но сделать можно иначе. Тут другой
VA>> вопрос, а нужно ли оно вообще кому-то?

DK> Было бы удобно, кстати. Например, когда кто-то кидает в эху ссылку на
DK> сообщение в другой эхе и по этой ссылке можно перейти сразу на
DK> сообщение. Тогда, было бы неплохо, если бы golded умел эти ссылки
DK> создавать по нажатии на какую-нибудь клавишу...

Я смотрел на эти ссылки давно, и не понимал - а как ими воспользоваться? Было некое ощущение ущербности.:)


Cheslav.


... Реальность отличается высокой скоростью рендеринга и отсутствием сюжета.
--- ...