Прочитанные, lastread, hi/low watermark

Zhenja Kaliuta написал(а) к Alexey Fayans в Jan 20 21:32:58 по местному времени:

Нi, Alexey!

On Fri, 10 Jan 2020 21:20:01 +0200 Alexey Fayans writes:

NA>>> НPT не берётся решать, где же закончится битое сообщение в пакете
NA>>> и начнётся следующее. Он засёк, что поле вышло за рамеры, после
NA>>> этого говрит, тут всё покарапчено, в бэды, главное никакой
NA>>> самодеятельности. НPT не работает тут в режиме hptutil fix.
ZK>> Ну вот не надо драматизировать. Всё было бы плохо, если бы следующее
ZK>> поле было по фиксированному смещению, а в данном случае как раз не
ZK>> так.

AF> Не удивлюсь, если половина софта, следуя такой спецификации, как
AF> раз ищет следующее поле по фиксированному смещению. Ведь это ж так
AF> просто, прочитать 72 байта в память сразу, расчитывая, что там
AF> где-то есть \0, и потом читать что там дальше должно быть. А потом
AF> ещё и упасть по Access Violation при попытке обратиться к этой
AF> строке, если там \0 не было нигде.

Ну так как сабжект может быть короче, то не сразу считывать 72, а таки
до NUL. Просто буфер можно сделать 72 байта. И то, что у фастехи буфер
оверфлоу если за это время она не встречает NUL, это печально, конечно.

Но не имеет ничего общего с "где закончится битое сообщение в
пакете". Всё там ясно, где закончится.

В плане, я не выступаю за сабжекты длиннее стандарта, но обработать эту
ситуация ничего не мешает (вот сабжект в спецификации Stored message --
совсем другая история).


--- Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

Vitold Sedyshev написал(а) к Dmitri Kamenski в Jan 20 00:26:49 по местному времени:

Нello, Dmitri!

DK> Нi Alexander!

DK> 10 января 2020 13:19, Alexander Kruglikov писал Sergey Anohin:

NA>>>> А вот можно левонетов нарезать сколько угодно и там
NA>>>> тренироваться.
SA>>> так в локалке то чем хуже тренироваться?

AK>> Тем, о чём я вчера написал. Вместе с тренировочными письмами в UTF
AK>> пропадают и письма в CP866

DK> Добиться непропадания писем просто вне зависимости от кодировки. Но кто их будет читать/отвечать?

Да елки моталки у всего софта есть исходники и добавить класс декодера для сообщения в тот же GoldEd и НPT исходники и перекомпилить
можно за несколько дней максимум, но просто гораздо проще сидеть и спорить.

DK> Bye Alexander!


С наилучшими пожеланиями, Vitold Sedyshev.

--- wfido

Nil Alexandrov написал(а) к Vitold Sedyshev в Jan 20 00:46:16 по местному времени:

Нello, Vitold!

Saturday January 11 2020 00:26, from Vitold Sedyshev -> Dmitri Kamenski:

VS> Да елки моталки у всего софта есть исходники и добавить класс декодера
VS> для сообщения в тот же GoldEd

Добавь, если такой умный, народ тебе спасибо скажет.

VS> и НPT исходники и перекомпилить можно за

НPT ничего не должен перекодировать - это будет модификация транзитных писем.

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

Alexey Fayans написал(а) к Zhenja Kaliuta в Jan 20 03:59:24 по местному времени:

Нello Zhenja!

On Fri, 10 Jan 2020 at 21:32 +0200, you wrote to me:

AF>> Не удивлюсь, если половина софта, следуя такой спецификации, как
AF>> раз ищет следующее поле по фиксированному смещению. Ведь это ж
AF>> так просто, прочитать 72 байта в память сразу, расчитывая, что
AF>> там где-то есть \0, и потом читать что там дальше должно быть. А
AF>> потом ещё и упасть по Access Violation при попытке обратиться к
AF>> этой строке, если там \0 не было нигде.
ZK> Ну так как сабжект может быть короче, то не сразу считывать 72, а таки
ZK> до NUL.

Можно считать всё, а смещение искать используя strlen(), подразумевая, что в прочитанном всё-таки будет \0.

ZK> Просто буфер можно сделать 72 байта. И то, что у фастехи буфер
ZK> оверфлоу если за это время она не встречает NUL, это печально,
ZK> конечно.

Там не оверфлоу, она не падает. Но какая у неё там логика - хз, исходников-то нет.

ZK> Но не имеет ничего общего с "где закончится битое сообщение в
ZK> пакете". Всё там ясно, где закончится.

Если всё делать по уму, то да. Но увы.

ZK> В плане, я не выступаю за сабжекты длиннее стандарта, но обработать
ZK> эту ситуация ничего не мешает (вот сабжект в спецификации Stored
ZK> message -- совсем другая история).

Тут не спорю, если не пытаться читать что там должно идти после сабжа по фиксированному смещению (если не встретили \0), всё будет ок. Я лишь предполагаю, что есть дофига софта, который делает именно так, и поэтому у него едет крыша.


... Music Station BBS | https://bbs.bsrealm.net | telnet://bbs.bsrealm.net
--- GoldED+/W32-MSVC 1.1.5-b20180707

Alexey Fayans написал(а) к Vitold Sedyshev в Jan 20 04:24:16 по местному времени:

Нello Vitold!

On Sat, 11 Jan 2020 at 00:26, you wrote to Dmitri Kamenski:

VS> Да елки моталки у всего софта есть исходники и добавить класс декодера
VS> для сообщения в тот же GoldEd

Ну ты юморист... :)

VS> и НPT

НPT вообще пофиг на кодировку. Это тоссер.

VS> исходники и перекомпилить можно за
VS> несколько дней максимум, но просто гораздо проще сидеть и спорить.

Ставлю сто баксов на то, что ты не сможешь добавить полноценную поддержку UTF-8 в GoldED за несколько дней (скажем, за 14).

Полноценная поддержка означает как минимум:

- Работая в режиме UTF-8 дедуля должен уметь отображать письма в других кодировках.
- Дедуля не должен портить базы, записывая мусор в служебные поля из-за некорректной проверки максимальной длины строки.
- Форматирование текста и, в особенности, цитат должно работать нормально.
- Поиск должен работать.
- Отображение списка писем (F9) тоже должно работать.
- Это не должен быть какой-то костыль вроде прикручивания iconv для перекодировки UTF-8 в CP866 на этапе чтения из базы или ещё что-нибудь в таком духе.. :)


... Music Station BBS | https://bbs.bsrealm.net | telnet://bbs.bsrealm.net
--- GoldED+/W32-MSVC 1.1.5-b20180707

Vitold Sedyshev написал(а) к Alexey Fayans в Jan 20 05:37:35 по местному времени:


AF> - Это не должен быть какой-то костыль вроде прикручивания iconv для перекодировки UTF-8 в CP866 на этапе чтения из базы или ещё что-нибудь в таком духе.. :)

Это единственное решение в случае с GoldEd. Если у Golded основная кодировка 8-bit и это скажем CP866, то входящее письмо нужно адаптировать для отображения в этой кодировке,
а все остальное это какие-то мне непонятные фантазии.

Можно конечно попробовать поковырять ncursesw или вообще переписать вывод скажем на виртуальную консоль, а ее отрисовать через обычный SDL, Xlib и т.д. но думаю,
что оно того не стоит просто.


--- wfido

Alexey Fayans написал(а) к Vitold Sedyshev в Jan 20 06:02:28 по местному времени:

Нello Vitold!

On Sat, 11 Jan 2020 at 05:37, you wrote to me:

AF>> - Это не должен быть какой-то костыль вроде прикручивания iconv
AF>> для перекодировки UTF-8 в CP866 на этапе чтения из базы или ещё
AF>> что-нибудь в таком духе.. :)
VS> Это единственное решение в случае с GoldEd. Если у Golded основная
VS> кодировка 8-bit и это скажем CP866, то входящее письмо нужно
VS> адаптировать для отображения в этой кодировке, а все остальное это
VS> какие-то мне непонятные фантазии.

Ну ты ж сказал, что легко можно сделать. Вот и попробуй. :) Ну или просто поверь, что не ты первый, кому это в голову пришло. Многие смотрели код и приходили к выводу, что внедрить нормальную поддержку UTF-8 в код дедули почти не реально, придётся переписывать всю обработку текста повсеместно.

Если же перегонять всё в восьмибитную кодировку на этапе чтения из базы, то какой смысл в UTF-8? Просто чтобы было? С тем же успехом можно на этапе тоссинга конвертировать через хуки/препроцессоры.

VS> Можно конечно попробовать поковырять ncursesw или вообще переписать
VS> вывод скажем на виртуальную консоль, а ее отрисовать через обычный
VS> SDL, Xlib и т.д. но думаю, что оно того не стоит просто.

Все порты, кроме DOS, могут работать нативно в UTF-8, система позволяет, так что проблема не в том, чтобы вывести UTF-8 на экран, а в том, как дедуля работает с текстом.


... Music Station BBS | https://bbs.bsrealm.net | telnet://bbs.bsrealm.net
--- GoldED+/W32-MSVC 1.1.5-b20180707

Sergey Anohin написал(а) к Vitold Sedyshev в Jan 20 10:54:40 по местному времени:

Нello, Vitold!

VS> Да елки моталки у всего софта есть исходники и добавить класс декодера для сообщения в тот же GoldEd и НPT исходники и перекомпилить
VS> можно за несколько дней максимум, но просто гораздо проще сидеть и спорить.

Не все хотят, по причине нежелания ковыряться из-за качества кода наверно :)

С наилучшими пожеланиями, Sergey Anohin.

--- wfido

Stas Mishchenkov написал(а) к Nil Alexandrov в Jan 20 11:44:02 по местному времени:

Нi, Nil!

09 янв 20 23:48, Nil Alexandrov -> All:

NA> В FTN есть понятие high номера для текущей эхи и lastread - обычно для
NA> какого-то пользователя (удобно для ББС когда их может быть много,
NA> кроме формата .msg где только один пользователь),

Ошибаешься. В MSG базе тоже есть многопользовательский lastread. Смотри файл lastread.

Нave nice nights.
Stas Mishchenkov.

--- На халяву не только уксус сладок, но и свинина постна, халяльна и кошерна.

Zhenja Kaliuta написал(а) к Alexey Fayans в Jan 20 11:07:03 по местному времени:

Нi, Alexey!

On Sat, 11 Jan 2020 03:59:24 +0200 Alexey Fayans writes:

AF>>> Не удивлюсь, если половина софта, следуя такой спецификации, как
AF>>> раз ищет следующее поле по фиксированному смещению. Ведь это ж
AF>>> так просто, прочитать 72 байта в память сразу, расчитывая, что
AF>>> там где-то есть \0, и потом читать что там дальше должно быть. А
AF>>> потом ещё и упасть по Access Violation при попытке обратиться к
AF>>> этой строке, если там \0 не было нигде.
ZK>> Ну так как сабжект может быть короче, то не сразу считывать 72, а таки
ZK>> до NUL.

AF> Можно считать всё, а смещение искать используя strlen(),
AF> подразумевая, что в прочитанном всё-таки будет \0.

В плане выделить сразу буфер под всё сообщение (там же 64K жёсткий лимит
вроде?) и читать в него по кускам а потом типа парсить?

Потому что если читать в динамические буфера то последующие манипуляции
(собирать тело из кусков, например) выглядят ненужным усложнением по
сравнению с просто читать до нужной точки.

ZK>> Просто буфер можно сделать 72 байта. И то, что у фастехи буфер
ZK>> оверфлоу если за это время она не встречает NUL, это печально,
ZK>> конечно.

AF> Там не оверфлоу, она не падает. Но какая у неё там логика - хз,
AF> исходников-то нет.

Ну падать не обязательно, можно переменные на стеке затереть. А
с нетмейлом можно объяснить тем, что тело обрабатывается с неверной
точки, т.е. нету AREA: в начале.

PS: это письмо -- чисто потрындеть.

--- Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)