#1
|
|||
|
|||
Широкие терминалы и 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 |
#2
|
|||
|
|||
Широкие терминалы и char buf[сколько не жалко].. StyleCodeНighlight()
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 |
#3
|
|||
|
|||
Re: Широкие терминалы и char buf[сколько не жалко].. StyleCodeНighlight
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 |
#4
|
|||
|
|||
Широкие терминалы и char buf[сколько не жалко].. StyleCodeНighlight
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 |
#5
|
|||
|
|||
Re: Широкие терминалы и char buf[сколько не жалко].. StyleCodeНighlight
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 |
#6
|
|||
|
|||
GoldED-NSF
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 |
#7
|
|||
|
|||
Re: GoldED-NSF
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 |
#8
|
|||
|
|||
GoldED-NSF
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) |
#9
|
|||
|
|||
GoldED-NSF
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 |
#10
|
|||
|
|||
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. ... Реальность отличается высокой скоростью рендеринга и отсутствием сюжета. --- ... |