Зачем всё в кучу пихать?

Ты о чём?

О calloc.

Ты про весь список?

Ты автор? Есть пара вопросов или советов, как сделать лучше.

editor - редактор используемый для просмотра текстовых файлов.

Почему не брать EDITOR из переменной окружения, как это обычно принято? В конфиге можно оставить, но опционально, чтобы можно было переопределить. Хотя обычно просто переопределяют переменную окружения EDITOR, если так надо.

редактор

для просмотра

Так для просмотра или редактирования? Если для просмотра, то можно использовать, скажем, less? Если да, то это не editor, а viewer явно.

Файл настроек должен лежать в $HOME/.rfcreader

Лучше бы в $XDG_CONFIG_HOME/rfcreades/rfcreader.conf с фоллбеком на $HOME/.config/rfcreades/rfcreader.conf

P.S. А вообще какой-то хелловорлд, уровня недавнего translate

P.S. А вообще какой-то хелловорлд, уровня недавнего translate

Но всё же, очень удобно. Какой нужно редактор, такой и можно вписать. Если нужен только viewer, то используй соответсвующее less, а vi это редактор, а не viewer, так что всё остаётся как есть.

Если нужен только viewer, то используй соответсвующее less

Я не знаю, что нужно, и зачем используется в этой программе. Если там можно что-то редактировать, то это редактор. Тогда надо в readme исправить «для просмотра» на «для редактирования». Если там «редактор» вызывается для просмотра (и вполне полноценное использование программы получается и в случае с less), то просто тот кто вписал туда vi, использует его не совсем по назначению, а в качестве viewer'а, и соответственно, должно быть не editor, а viewer.

А если понадобиться функционал vi например, например нужный абзац скопировать в другой файл, или что нибудь другое, всё же редактор нужнее.

А если понадобиться функционал vi например, например нужный абзац скопировать в другой файл, или что нибудь другое, всё же редактор нужнее.

Понадобится он пользователю или нет, решать пользователю. К редактированию это не относится, и vim будет в данном случае выступать в роли viewer'а.

всё же редактор нужнее.

Редактировать надо? Если нет, то не нужнее. Описано, что нужнее конкретно функции, имеющиеся в vim. А не конкретно редактор. vim != редактор. Он лишь является редактором. Довольно популярный nano тут чем-нибудь поможет? Видимо нет.

Не надо вводить пользователя в заблуждение или считать его за идиота. Если нужно указать программу, которая используется для просмотра, то это должно называться viewer. А юзер уже сам решит, нужно ему туда вписать nvim или less.

Пользователь должен знать что можно использовать редакторы для просмотра. Этот viewer без функций редактора накладывает какие-то ограничения на действия пользователя. Ну ты знаешь что можно редактор использовать, если я бы например например написал viewer=less или less=less типа такого, то ты наверное написал бы, что редакторы тоже можно использовать, типа что viewer не подходит тогда для такого названия.

Ты про весь список?

Я в код особо сильно не вникал, но вот что сразу бросилось в глаза.

• Зачем выделать память под struct configs на куче? Можно сделать, чтобы getconfig принимал указатель на структуру и просто заполнял её:

  struct configs cf;
  getconfig(&cf);
  

• Зачем выделать память под поля структуры getconfig на куче, если у тебя всё равно не поддерживаются строки длиной более 127 символов?
• Зачем вообще выделять память на куче для строк, длина которых известна на этапе компиляции?

При всём этом у тебя на 14 вызовов calloc один вызов free. Понятно, что в твоём велосипеде к реальным утечкам это не приведёт, но всё равно высвобождать выделенную ранее память — это хороший тон.

Ну и плюс ты и с calloc косячишь:

• Вопрос на засыпку (отсюда): чему равно sizeof(1)?
• Тут и тут и ещё в куче мест у тебя не выделяется память под символ ‘\0’.

Вопрос на засыпку (отсюда): чему равно sizeof(1)?

равно 4.

продолжение

• Под choices у тебя память неправильно выделяется. Ты создаёшь массив строк, на не массив символов, нужно как-то так:

  char **choices = calloc(choices_size, sizeof *choices);
  

  И зачем выделять именно 65535 элементов? Не проще выделить какое-то разумное количество, а в случае необходимости сделать realloc?

  Ну и в C не нужно кастовать void-указатели к другим типам указателей.

• Без goto у тебя вполне можно обойтись.

Помимо вышеупомянутых замечаний, хочу сказать, что даже на первый взгляд код не очень хороший и нуждается в серьезном рефакторинге. Кроме кривоватого форматирования, очень много различных магических чисел, которые хорошо бы вынести в константы, не нужный goto, пляшущий стиль (местами char *, местами char*) и т. д.
По-моему прежде чем выкладывать программу для использования и вообще в open source, неплохо было бы попросить кого-нибудь из опытных разработчиков провести ревью.

Как говорилось в какой-то книжке

написать можно всё что угодно, всё зависит от стиля.

Да нормальный код.

Да нормальный код.

http://cs5.pikabu.ru/post_img/big/2015/12/04/5/1449210847155432089.jpg

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

Это не как попало. Я знаю что такое в одном стиле. Но это как меня устроит а не как тебя. Придерживаются тому стилю, которому захочет придерживатся главный. Ничего не случиться. А раз я написал этот код, то я придерживаюсь своего стиля. Если для тебя char * и char* плохой стиль написания, то это для твоего стиля. А я как захочу так и напишу, это мой стиль.

Пользователь должен знать что можно использовать редакторы для просмотра.

Он это знает благодаря тому, что не идиот. Твоя программа для идиотов? Тогда все вопросы снимаются.

Ну ты знаешь что можно редактор использовать, если я бы например например написал viewer=less или less=less типа такого, то ты наверное написал бы

Нет, потому что viewer используется для просмотра. Если я для просмотра хочу использовать vim, то в данный конкретный момент у меня vim — viewer.

rfcreader — удобная навигация по rfc-документам

Я уж думал, что оно RFC по всему инету ищет, а тут лишь навигация по тем, которые на харде лежат…

Я всё правильно написал. Редактор использовать для просмотра. Я же не написал viewer=vi , редактор используемый для просмотра. Редактор тоже используется для просмотра, а если что нибудь понадобиться, то можно использовать возможности редактора. Можно конечно использовать less, но это по желанию. Но vim это редактор, ты просто из его функциональных возможностей используешь только просмотр файла.

А так удобно да? Нет инета, есть коллекция rfc документов, есть rfcreader и удобный поиск.

Ясно, у тебя логика сломана вообще наглухо.

Ну и, как ты думаешь, у многих ли возникнет такая ситуация? Я не знаю никого, кто бы скачивал себе RFC — они могут потерять актуальность, их надо обновлять по мере выхода новых, etc. Гораздо удобнее смотреть последние прямо из сети. В прочем, дело твоё

1. Зачем комбайн?
2. Зачем readme на русском?
3. Зачем вообще русский в репе?
4. Где описание того, что такое rfc? Я вот не знаю, что это такое.
5. Прикладной софт на С? Вы в каком веке живёте?
6. Где сравнение с конкурентами? Что может дать прога в 300 сток, в отличии от них?
7. Половина файлов в репе пустые.
8. makefile ужасен

Где сравнение с конкурентами? Что может дать прога в 300 сток, в отличии от них?

Я незнаю программ для работы с rfc.

Где описание того, что такое rfc? Я вот не знаю, что это такое.

Ну если незнаешь, тебе должно быть интересно.

makefile ужасен

А что ужасного?

Зачем readme на русском?

Можешь перевести на английский и читать английский текст.

Прикладной софт на С? Вы в каком веке живёте?

Опыт.

Зачем вообще русский в репе?

Чтобы русский тоже был.

Половина файлов в репе пустые.

Ну где-то пусто щас.

Чтобы русский тоже был.

Для этого подучите русский.

А что ужасного?

path вшит. Ofast ненужно.

Опыт.

Пишите патчи в ядро. В прикладном софте Си не нужен.

Зачем readme на русском?

У него английский ещё на пару порядков хуже, чем русский (а русский сам видишь, какой, уровня «незнаю»), а точнее гуглтранслейт, в предыдущей мегаразработке уже выяснили. Уж лучше пусть так будет, чем пытаться угадывать, что «way» это на самом деле «path» и прочие перлы, так хоть понять возможно.

Понятно. Предыдущую тему прогавал.

Ну да, последние обновления в сети можно скачать,но всёже, посмотри как удобно. https://github.com/xverizex/rfcreader/blob/master/about.mkv]

Пишите патчи в ядро. В прикладном софте Си не нужен.

Да лучше на си написать, на нём быстрее. Можешь удалить прикладной софт на си и использовать на других языках.

mkv
git

Facepalm. Не надо так делать, есть же ютуб

Быстрее что? Разработка - нет. Работа проги? В вашем случае - без разницы.

А ты сравнивать то будешь? Если да то с чем? Я знаю пока что самую удобную и быструю прогу, так это мою. В ней есть то что нужно. Она может понадобиться кому то, не только мне. Ты пользуешься rfc? Ты сможешь найти прогу лучше моей?

Это временно, я уже собираюсь удалять. На ютуб не хочу выкладывать.

самую удобную

Вкусовщина. Мимо.

быструю прогу

Если не с чем сравнивать, то относительно чего она быстрая?

Вкусовщина. Мимо.

С чем сравнил?

Если не с чем сравнивать, то относительно чего она быстрая?

Если есть с чем сравнить, то быстрее или медленнее. Если быстрая, то значит быстро выполняет нужную задачу.

Вам к доктору, а не ко мне.

А что ужасного?

например цели clean, install лучше сделать .PHONY

Ну как-то так.

curl -s https://www.rfc-editor.org/in-notes/rfc-index.txt|grep -i SMTP
curl -s https://www.rfc-editor.org/rfc/rfc4496.txt|less

curl -s https://www.rfc-editor.org/in-notes/rfc-index.txt|grep -i SMTP

Там описания тянутся на несколько строк, так что все не так просто.

Я заметил. Можно для других форматов накостылять искалок.

Тот файл был временным. Я уже сделал с помощью autotools.

У меня лучше.

с помощью autotools.

Болезнь прогрессирует.

В прикладном софте Си не нужен

иди-ка ты нахер с такими аргументами. человеку удобно — он пишет. не лезь

Чем?

http://www.unfire01.ru/uploads/tx_labshop/ognetushiteli_uglekislotnye_2.jpg

Судя по срачу в комментариях, автор — типичный школьник с синдромом Творца. Это пройдёт, если достаточно часто и настойчиво макать его лицом в результаты его творчества. Впрочем, в данном случае процесс лечения обещает быть весьма трудоёмким.

Нужен каталог с документами rfc.

Я бы сказал, что это фатальный недостаток.