Выпуск Thalassa CMS 0.1.10

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

В каком случае? В sway? Ну так в массиве не всегда чары хранятся. Там могут лежать объекты побольше. И их там могут быть тысячи. И очередной вызов realloc вернет null. И после этого будет сегфолт при обращении к этой памяти.

Обработка ошибок это несомненно важно, но как и Столяров я все же склонен считать что проверять malloc() это не самое важное занятие, я вообще мало знают программ которые этим занимаются полноценно, и почти не знаю таких которые могут сделать что то кроме exit/abort.

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

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

Ложная дихотомия же. Никто не говорит, что wordpress лучше.

но как и Столяров я все же склонен считать что проверять malloc() это не самое важное занятие

И так же как Столяров, ты имеешь гипертрофированное ЧСВ, не позволяющее тебе понять, почему ты неправ.

А что лучше? Если взять требования автора, то приходим ко мнению что ничего. Я таких проблем из другого софта тоннами наберу. Это норма.

Требования автора – такое же дерьмо, как и его код

Это называется альтернативное мнение.

Я таких проблем из другого софта тоннами наберу. Это норма.

В мире очень много быдлокода, что поделать.

Все так, поэтому не вижу где Столяров тут отличился в худшую сторону. Писать как нужно это невероятный труд, лучше потратить 30% времени и получить 70% качества.

Это называется альтернативное мнение.

Это называется «профнепригодность»

Повторю тут код:

    int ll = strlen(a_value);
...
        int lv = strlen(value);
        char *newval = new char[lv+1+ll+1];
        snprintf(newval, lv+1+ll+1, "%s,%s", value, a_value);
        delete[] value;
        value = newval;

Подумай ещё раз над своим ответом.

В коде кстати есть проблема, да, но специалист по формальным придиркам Siborgium в совём комменте это в упор не заметил, ведь эта проблема не модная.

Проблема в том что там int, да ещё и signed - я регулярно писал о том, что сувать везде signed int - это вредная легаси-привычка из 80-х, мне в ответ некоторые даже возражали и приводили какие-то модные методички о том что надо избегать unsigned-ов. И вторая проблема, впрочем она очень часто бок о бок идёт с первой - там нет проверки на переполнение при сложении. Кстати, сможешь её корректно организовать, или у тебя тоже int-мания имеется?

И вот если бы это всё выше было сделано корректно, то проверку >INT_MAX следовало делать не из возвращаемого значения snprintf, а из значения (size_t)(lv+1+ll+1). После неё никаких неожиданностей в snprintf уже быть не может. А лучше вообще убрать snprintf и заменить на два memcpy и одно присваивание.

Проблема в том, что сбой malloc может произойти когда угодно, и это может привести к повреждению данных, если ты не сделаешь graceful shutdown. А если на данные пофиг, то как минимум сегфолт по разыменованию NULL из-за сбоя malloc по логам неотличим от выхода за пределы региона или ошибки программирования. Если не хочется обрабатывать malloc по-честному, то надо хотя бы завернуть его ассерт (при этом запретить компиляцию с NDEBUG, разумеется), чтобы было видно, где конкретно случился сбой. Если религия позволяет - использовать xmalloc.

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

Это проверка из snprintf(). Ты спросил, что может вернуть? Вот это может.

Писать как нужно это невероятный труд, лучше потратить 30% времени и получить 70% качества.

Невероятный труд сделать макрос? Приехали, лол.

Писать как нужно это невероятный труд

Бардак в голове - бардак в коде.

Я не зря тебе привёл код. Вторым аргументом snprintf-а там суётся int. Так что эта проверка идёт мимо.

The C standard and POSIX specify that the behavior of sprintf and its variants is undefined when an argument overlaps with the destination buffer.

https://en.cppreference.com/w/c/io/fprintf

Любой нормальный человек проверит размер перед вызовом sprintf

Я не зря тебе привёл код. Вторым аргументом snprintf-а там суётся int. Так что эта проверка идёт мимо.

Ты можешь продолжать отрицать реальность, я никак не могу тебе помешать.

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

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

Ну или тогда хотя бы будь последовательным - при старте проверяй значение vm.overcommit_memory и предупреждай пользователя, мол «У вас небезопасная для этой программы настройка, если хотите продолжать пользоваться программой, то ССЗБ»

Нет, фейлы snprintf от реализации не зависят, при условии что реализации не бажные и на вход поданы корректные данные.

Где об этом написано? Покажи место в стандарте.

при условии что реализации не бажные

В Деда Мороза ты тоже веришь?

я все же склонен считать что проверять malloc() это не самое важное занятие

один раз написать макрос и потом его в коде юзать - эт конечно титанический труд, базару ноль xD

Нет, я говорю о всех правилах.

Нет, я говорю о всех правилах.

Правил ровно два: не порти память и не делай UB. Это не сложно.

и на вход поданы корректные данные

Вот корректность данных он и не проверяет. Раз по стандарту ситуация, когда размера строки, в которую пишет символы sprintf меньше необходимого – UB, размер выделенного буфера надо проверять.

Причём тут sway и realloc? Речь про проверку возврата snprintf во вполне конкретном куске кода, на который дали ссылку.

А sway конечнчо же не нужен, как и все вайландоподелки.

не делай UB

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

Больно это признавать, но факт состоит в том, что наверное в целом мире не существует человека, который способен писать на С++ без ошибок.

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

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

Так и отлично, Croco отрицает все кроме new и delete.

Верно, перед вызовом надо проверять а не после, как некоторые тут советуют. О чём и спор был.

Что ты несёшь?

int n;
if(n>INT_MAX) { ... }

Что ты несёшь?

Просвещение, которое ты упорно отрицаешь. Я буквально скопировал тебе проверку из musl. Ты упорно отрицаешь что этот код там есть. Что я могу поделать? :D

А sway конечнчо же не нужен, как и все вайландоподелки

Любопытно, если Столяров не проверяет размеры строк и просирает дескрипторы – все хорошо. Если то же самое делают разработчики свай – они быдлокодеры, потому что вайланд ненужен. Тебе от собственного лицемерия и двоемыслия не тошно?

А вайланд нужен. Потому что иксы – дерьмо

Учись читать. Я не отрицал что где-то есть эти строки, я писал что они нерелевантны текущему вопросу.

Учись читать. Я не отрицал что где-то есть эти строки, я писал что они нерелевантны текущему вопросу.

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

Опять мои слова перевирают.

Я не писал ни первого ни второго. Если считаешь что писал - приводи точные цитаты, только не допускай дыр в логике перехода от моих цитат к своим их интерпретациям.

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

Опять мои слова перевирают.

Просто никто не понимает твой шизофазии, сорян.

Верно, перед вызовом надо проверять а не после, как некоторые тут советуют

После – тоже нужно. Из документации:

If an output error is encountered, a negative value is returned

Вайланд просто не нужен

Вайланд просто нужен. Потому что во всех современных операционных системах, предоставляющих графический интерфейс (Windows NT, osX, android) есть нормальный графический сервер. Только в линуксе говноиксы с тирингом, тормозами и уязвимостями, а так же с отсутствием нормального протокола для захвата экрана. Вайланд эти проблемы решает.

Я не писал ни первого ни второго

Когда речь шла про Столярова, ты рассказывал, что его баги – кого надо баги и их нельзя критиковать, как только речь зашла про sway – ты вспомнил, что sway ненужен

Кто-то придет к автору и создаст в багтрекере запись

Бгг.

Вайланд эти проблемы решает.

Не, не решает. В Wayland нет протокола для захвата конкретного окна, например.

output error это про write() и подобное.

Теоретически может быть дефективная реализация sprintf с malloc-ами внутри, которые могут сделать ENOMEM (плавно переходим к вопросу о том, может ли malloc вернуть NULL, и не удивлюсь если в glibc такая и есть), но на такое практически никакой код не рассчитан.

Вообще, я sprintf несколько избегаю последнее время, это древняя функция из тех же 80-х и раньше, одно то что у неё int тип возврата уже плохой знак. Написал себе замену ей, в которой гарантированно нет malloc-ов и других скрытых возможностей упасть, в которой нет int-ов вместо size_t и прочих проблем, стараюсь использовать её.

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

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

Когда речь шла про Столярова, ты рассказывал, что его баги – кого надо баги и их нельзя критиковать, как только речь зашла про sway – ты вспомнил, что sway ненужен

Нет. Читай внимательнее, возразил я только заявлению про код возврата snprintf и наезду на кодстайл. И там же сразу согласился про некрасивую работу с выделением памяти.

А про то что sway не нужен я вспоминаю каждый раз как про него речь заходит, вне зависимости от контекста. Просто тут ещё удачно сложилось.

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

Только что шарил экран в вайланде. Для этого есть xdg-desktop-portal.

Проблемы иксов надо фиксить патчами на иксы,

Так-то в развитии Wayland участвуют ключевые разработчики Xorg. Один из них за долгие годы работы над кодом иксов удалил гораздо больше кода, чем добавил. Видимо, проще было написать с нуля.

Это не разработчики, это засланцы-диверсанты. Разработчики на пенсии, к сожалению.

Только что шарил экран в вайланде. Для этого есть xdg-desktop-portal.

Я тоже могу зашарить экран. Как мне зашарить окно?

Это не разработчики, это засланцы-диверсанты.

Сходи к психотерапевту что ли.

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