Выпуск Thalassa CMS 0.1.10

И правда, зачем проверять код его возврата? Там он и не проверяется.

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

А с управлением памятью да, не очень красиво, хотя формально всё рабочее.

То что strlen два раза считается, например. И то что не используется strdup либо её самописный аналог, а вот так прям на месте эти alloc+copy каждый раз.

А что там не так с копированием строки?

Там минное поле из strlen, strcpy и друзей.

Я думал что то серьезное.

Вообще, это забавно. Всякие стенсоны и Столяровы, хаящие все новое и обсирающие «хипсторские языки для скриптомакак» сами пишут какую-то хтонь.

Пока что крупнейшая утечка в этой cms отберет памяти меньше чем весит Cargo.toml в Hello World на Rust.

И правда, зачем проверять код его возврата?

Действительно. Зачем вообще ошибки обрабатывать? Можно еще делать вещи типа:

char *string = malloc(20);
string = realloc(string, 1000);

Кстати, в исходниках sway такие художества действительно есть.

Вы не панимаити, эта панарошку! Это труеЪ язык! Не то, что ваши хипстерские говнорасты!!!

Тебе самому не смешно?

Я не вижу ничего ужасного в этом проекте, намного лучше очередной cms под два гигабайта. Ошибки не очень серьезные, но конечно автору стоит узнать о стат анализе и тестировании.

А тут что не так?

А если внимательно почитать man 3 realloc?

Уже читал, так что же тут не так?

Я не вижу ничего ужасного в этом проекте, намного лучше очередной cms под два гигабайта

Нет, лучше CMS под два гигабайта, в которой нет текущей памяти и просраных дескрипторов, чем это «минималистичное» поделие.

Я не думаю что потеря дескриптора файла конфигурации отнимет хотя бы один мегабайт.

Уже читал, так что же тут не так?

Нет, ты не читал, а дрочил. Если бы ты читал, ты бы узнал, что realloc в случае неудачи, возвращает NULL.

Я не думаю что потеря дескриптора файла конфигурации отнимет хотя бы один мегабайт

Все так «не думают». А потом в ping из FreeBSD очередная Use-after-free уязвимость. Или в ядре Linux. Или в systemd.

И правда, зачем проверять код его возврата? Там он и не проверяется.

Затем, что функция может зафейлиться по целому ряду причин, и дальше программа пойдет ломать валидные данные, прежде чем свалится в сегфолт (если повезет). А если нет - вот у тебя классическое место для потенциальных уязвимостей разного рода.

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

А еще код никогда не должен работать в неопределенных условиях, потому что это влечет риск уязвимостей или порчи данных. Между выбором «делать что-то странное» и «упасть», следует всегда выбирать второе.

Поскольку Croco теоретик, он либо не знает эти правила, либо игнорирует их, считая себя самым умным. Я у него, скорее всего, в игноре, так что донесите ему кто-нибудь этот пост, пожалуйста. Попробуем научить его программировать нормально %)

Все так думают, а потом [подставить любое неприятное событие].

А теперь попробуй тоже самое при vm.overcommit_memory=2

Вообще, это забавно. Всякие стенсоны и Столяровы, хаящие все новое и обсирающие «хипсторские языки для скриптомакак» сами пишут какую-то хтонь.

Always has been. Я на собеседовании всегда прошу чувака назвать мне хотя бы три его нелюбимые вещи в языке. Если чувак говорит «hurr durr язык идеален», это повод покопать дальше :D

memset(&p[i * (j - 1)], 0, i);

Который может быть выкинут оптимизирующим компилятором. Кроме того, free()нужем, чтобы сообщить аллокатору о том, что эта память теперь свободна и ее можно использовать дальше. memset этого не делает.

Можно еще память дверью прищемить, но зачем?

$ ulimit -Sv 1
$ ./a.out 
Segmentation fault

😱

К чему ты смайлики ставишь, клоун? Тебе показали, что твой код будет работать не так, как ты рассчитывал. Код, который ты написал для случая с возвратом NULL не выполнится, твоя программа просто упадет с сегфолтом.

Твой код как раз таки не будет работать с проверкой ошибок, ведь я запущу его под Multics где не будет malloc, и даже компилятора С. К тому же ты не проверил хватит ли у тебя стека для нового кадра функции.

На 99% машинах malloc у этой CMS на которых она будет запущена, никогда не вернет NULL. Более того, то что это поведение по умолчанию в линуксе, намекает на то что проверка malloc на NULL в целом не имеет большого значения.

На 99% машинах malloc у этой CMS на которых она будет запущена, никогда не вернет NULL. Более того, то что это поведение по умолчанию в линуксе, намекает на то что проверка malloc на NULL в целом не имеет большого значения.

А если он запустит это в контейнере с лимитом памяти? На openbsd, где ЕМНИП нет overcommit? Сперва пишут непортируемое говно, а потом кукареку очередная дыра.

Тогда приложение закроется, а вот если бы он добавил туда проверку!!! Тогда бы оно проверило что p == NULL и закрылось...

На 99% машинах malloc у этой CMS на которых она будет запущена, никогда не вернет NULL

Потому, что ты так сказал?

Твой код как раз таки не будет работать с проверкой ошибок, ведь я запущу его под Multics где не будет malloc, и даже компилятора С. К тому же ты не проверил хватит ли у тебя стека для нового кадра функции.

Вы не панимаити, эта панарошку! Это труеЪ язык! Не то, что ваши хипстерские говнорасты!!!

«Ну и что, что все полетит с сегфолтом? Ну и что, что пользователю придется долго трахаться с дебагом моего говнокода? Зато я не какой-нибудь пидорас, пушущий на хипсторском говноязычке, а Ъ-хацкер»

Собственно, в этом и заключается позиция Столярова. В том, что код подобного «качества» нормальным людям не нужен, такие «труеъ-хацкеры» видят жидомасонский заговор тупых скриптомакак.

Это клоун из тредов про метапрог, не трать на него время. На конструктивный диалог не способен, интеллектом не обладает. Вон, даже на сегфолте начал кривляться, когда я его потыкал носом в его баги.

И причём тут snprintf? Какие ошибки он может вернуть в том конкретном случае на который ты жаловался?

Можно баг увидеть?

Да, вон он выше, в виде сегфолта. Где обработка ошибок?

Фейспалм я твой вижу, по существу есть что возразить?

Тогда приложение закроется, а вот если бы он добавил туда проверку!!! Тогда бы оно проверило что p == NULL и закрылось…

Оно не закроется, оно упадет к чертям в sigsegv. Кто-то придет к автору и создаст в багтрекере запись: спасите памагите у меня тулза в сегфолт валится. Чтобы этого не делать умные люди либо обрабатываются ошибки, либо делают макрос типа такого:

inline void *
xmalloc(size_t bytes)
{
    void *ptr = malloc(bytes);
    if (!ptr)
        exit(1, "out of memory");
    return ptr;
}

Но нет, мы будет падать в сегфолт на ошибках, мы же же сишные пердоли.

Затем, что функция может зафейлиться по целому ряду причин, и дальше программа пойдет ломать валидные данные, прежде чем свалится в сегфолт (если повезет). А если нет - вот у тебя классическое место для потенциальных уязвимостей разного рода.

И зачем ты мне эту графоманию суёшь? Повторю вопрос: по какому такому ряду причин может зафейлиться snprintf?

Оно не закроется, оно упадет к чертям в sigsegv. Кто-то придет к автору и создаст в багтрекере запись: спасите памагите у меня тулза в сегфолт валится.

Так и будет если стоит проверка на NULL, я же уже выше показал. Пользователей без мутных настроечек и ОС большинство.

Так выше еще, ты видимо упустил, я там пример с обработкой ошибки кидал, и он упал.

Так и будет если стоит проверка на NULL, я же уже выше показал.

Ты выше показал какую-то шизу.

Пользователей без мутных настроечек и ОС большинство.

Сказал, как настоящий быдлокодер.

Ну давай перефразирую если тебе непонятно, 99% пользователей запустят софт в такой конфигурации, что он упадет даже с проверкой, есть вообще смысл заниматься лишними движениями ради 1% что бы вместо sigsegv они получили другое сообщение об ошибке?

Для особо одаренных поясняю: совершенно не важно, по какому ряду причин может зафейлиться snprintf. У функции есть возвращаемое значение. Функция реализуется по принципу черного ящика, поэтому ты не можешь утверждать, что она НЕ сфейлится, потому что это зависит от конкретной реализации.

Есть код возврата - проверяй. Точка.

С одной стороны ты прав, с другой стороны это С, и стандарт определяется уже поведением текущих компиляторов и libc, а не наоборот.

Ну давай перефразирую если тебе непонятно, 99% пользователей запустят софт в такой конфигурации, что он упадет даже с проверкой, есть вообще смысл заниматься лишними движениями ради 1% что бы вместо out of memory они получили другое сообщение об ошибке?

Зачем освобождать память, если можно просто перезапустить сервис? Зачем обрабатывать ошибки, если у 99% пользователей ФС никогда не вернет ошибок?

Давай, жги ещё, этому треду нужно больше клоунады!

Ну быдлокодеры ну дают, лучше накатить православный WordPress, на PHP, где автор выдает такую базу:

Yeah it works but you’re leaking memory everywhere. Perhaps we should fix that. I’ll just restart Apache every 10 requests.

Не говоря уже о том, что на этом мемсете все и сегфолтнется, после того, как realloc вернет null

Он упал еще до того, как main начал выполняться, в районе всегих подгрузок so-шек. Как разработчик конкретной софтины, ты сделал всё что мог, остальное уже на совести разрабов нижележащего софта. Что-то тоже сделано плохо, видимо. Потому что если начать поднимать лимит, то можно увидеть вот что:

$ ulimit -Sv 1000
$ ./a.out
./a.out: error while loading shared libraries: libc.so.6: failed to map segment from shared object

memset для этого и нужен, иначе цикл остановится не скоро.