Опубликованы корректирующие обновления стабильных веток DNS-сервера BIND 9.11.22 и 9.16.6, а также находящейся в разработке экспериментальной ветки 9.17.4. В новых выпусках устранено 5 уязвимостей. Наиболее опасная уязвимость (CVE-2020-8620) позволяет удалённо вызвать отказ в обслуживании через отправку определённого набора пакетов на TCP-порт, на котором принимает соединения BIND. Отправка на TCP-порт аномально больших запросов AXFR, может привести к тому, что обслуживающая TCP-соединение библиотека libuv передаст серверу размер, приводящий к срабатыванию проверки assertion и завершению процесса...Подробнее: https://www.opennet.me/opennews/art.shtml?num=53577
вот бы на расте писали бы его и небыло
А где в новости про переполнение буфера, Фракталушка? Там билиотека корректно определяет размер, а проге большие пакеты не нравятся и она решает корректно завершиться. Т.е. проблема в алгоритмах, от чего Ржавый не спасёт.
> она решает корректно завершитьсяРешение грохать весь процесс из-за некритичной для работы приложения ошибки -- это именно си-стайл-решение. Оно и понятно, ведь все ошибки надо обрабатывать прямо здесь и прямо сейчас, а такой штуки, как исключения, в си нету. А потому ничего не остается, кроме как тупо завершиться.
Это как если бы ты увидел в этом предложении очепяткуAssertion error: unknown word "очепятку"
В расте тоже нет исключений.
Для обработки ошибок не всегда нужны исключения. Но обработчики ошибок надо же писать, проще просто написать assert не задумываясь о последствиях
Докажешь что не задумываясь?
Я вот вижу что обмозговали и поставили assert.PS: А не с жЫсЫ проггером ли я спорю? Пойду руки помою на всякий ...
Это не была обработка ошибок. Ассерт в данном случае использован совершенно корректно для проверки инварианта.
Вы "писали бы его" на расте -- его и нет, что характерно...
На расте бы это никогда не написали. Да и не напишут.Рас это такие розовые очки. "Вот иесли бы да кабы..." но так сказкой и остаётся.
Rust просто неадекватно переусложнён. Хеллоуворлды на нём выглядят красиво, а как что-то сложнее - так даже глаза за символы зацепиться не могут.А так DNS сервера даже на JS бывают https://www.npmjs.com/search?q=dns%20server
Пиши на Ziglang
Напиши, а после удали и раст заодно тоже
Подход долбанов, вместо обработки даже самых простых ошибок сразу крашить приложение
Подход долбанов -- это когда опыта нет, а мнение есть. Тебе не приходилось сталкиваться с ситуацией, когда в твою функцию через аргументы закидывают указатель, и ты в документации к ней написал, что указатель должен быть !NULL, но тем не менее, зная как это бывает, решил написать:if(ptr == NULL) {
// ???
}Вот ты написал это, и что ты будешь писать вместо ??? ? Какое осмысленное действие можно совершить, кроме уронить приложение к чертям? Как вообще можно осмысленно реагировать на то, что кто-то зачем-то засунул тебе NULL туда, куда NULL пихать нельзя?
Есть один способ: можно закладывать в API возможность выкинуть совершенно любую ошибку, в надежде что вызывающий код сможет найти способ отреагировать осмысленно. Но для этого а) надо закладывать возможность выкинуть любую ошибку, б) для вызывающего кода эта ошибка, практически наверняка, будет такой же бессмыслицей: то есть если программист даже и допустит возможность такой ошибки, он не сможет найти осмысленного способа отреагировать.
Обработка ошибок -- это очень занятная штука: если проследить весь путь ошибки от места, где код решил, что это ошибка, и до того места, где есть возможность ошибку обработать осмысленно (а не просто преобразовать к другому типу ошибки и пробросить дальше), то можно много чудных открытий сделать: например, смысл ошибки меняется по мере размотки стека. В момент детекта ошибки, это был unexpected char, потом эта ошибка превратилась в spurious brace, потом в malformed indexing operator invocation, а затем вдруг в YOUR CONFIG FILE HAD BEEN EDITED BY A MORON, GO AND FIX IT NOW.
Зачёт, нравится читать когда осмысленно пишут и со знанием дела.
> кто-то зачем-то засунул тебе NULL туда, куда NULL пихать нельзяЕсли контракт нарушен программистом (id est контролируемым источником), крашиться не только можно, но и нужно. Так быстрее обнаружим ошибку. В некоторых языках твои нуллы отловятся еще на этапе компиляции, так что не получится даже запуститься, чтобы закрашиться.
Если контракт нарушен пользователем (id est неконтролируемым источником), крашиться нельзя.
Если на ноль делит программист непосредственно в исходниках -- крашимся. Если делит на ноль пользователь в гуйном калькуляторе -- не крашимся и показываем ошибку. Отличаешь ситуации? В новости именно второй вариант.
Крешиться или нет это вопрос критичности участка кода. Если ситуация такая, что дальнейщее исполнение алгоритма теряет смысл, то останавливаем исполнение. Крах и немедленная остановка процесса исполнения - разные вещи.>Если на ноль делит программист непосредственно в исходниках -- крашимся.
Это должен отловить компилятор, как тоже самое отлавливает ЦПУ или рантайм любого языка. И собственно происходит выброс исключения которое можно обработать.
Если тебе по сети пришел неправильный пакет, ты это обнаружил и уронил все, вместо того чтобы:
отбросить пакет, записать в лог о наличии неправильного пакета. Но долбаны предпочитают крашить.
Ситуация с NULL поинтереснее, если есть возможность вернут ошибку выше - то лучше вернуть ошибку, а не уронить все сразу. Если нет возможности вернуть ошибки, значит тут выхода больше нет.
> Если тебе по сети пришел неправильный пакет, ты это обнаружил и уронил
> все, вместо того чтобы:
> отбросить пакет, записать в лог о наличии неправильного пакета. Но долбаны предпочитают
> крашить.
> Ситуация с NULL поинтереснее, если есть возможность вернут ошибку выше - то
> лучше вернуть ошибку, а не уронить все сразу. Если нет возможности
> вернуть ошибки, значит тут выхода больше нет.Ты не думал, что эти ситуации могут жить совместно?
Пришёл неправильный пакет, ты это обнаружил, но лишь по косвенным признакам: тебе прилетел NULL туда, куда не должен прилетать. Что ты будешь делать?
Ну, точнее не так, это не ты обнаружил неправильный пакет, всё что ты обнаружил, что твоя программа иногда получает NULL там, где его не должно быть. Копая глубже, ты выяснил, что в процессе разборки запроса был упущен какой-то вариант кривости запроса, и вместо генерации ошибки, была сгенерирована кривая структура, описывающая этот запрос. Кривая структура ушла дальше на выполнение, и там вдруг образовался NULL в переменной, которая NotNULL. Но все эти копания произошли позже, уже после того как программа упала. А упасть она смогла, вместо выхода за границы массива, благодаря тому, что ты поставил assert в том месте, где по идее не могло быть NULL, или len>=size, или ещё чего-нибудь. Ты не видел как такое может случится, ты не знал как реагировать на то, что на твой взгляд не может случится, но на всякий случай подстраховался assert'ом.
> программа иногда получает NULL там, где его не должно бытьЕсли быть более точным, функция, которой ты воспользовался, вернула NULL. Смотришь в доки -- да, говорится, что может вернуть NULL. Ты отличаешь NULL, который тебе передали в аргументах в нарушение контракта, от нулла, который ты получил сам, вызвав nullable-функцию?
Вот, вот. Нулл всегда можно обработать если есть эдакий "контракт".
И в коментах ниже каждый смотри с разного уровня. Кто сверху в низ, кто с низу в верх. И каждый пытается конкретный случай притощить как универсальное решение.Ребята вы все правы.
Я - прав. By definition (C) ;-p
Всё верно!
Фактически assert это своего рода документирование контракта. Т.е. предполагается, что дальнейший код написан с учетом этого допущения, т.е. что ptr != NULL.
Но это не значит, что он не мог быть написан иначе, просто такой контракт.
Далее вызывающая сторона должна что-то с этим решать, т.е. либо обеспечить этот контакт самостоятельно или "экспортировать" контракт выше.
Как видно, в данном случае контракт, что условный ptr != NULL был экспортирован вплоть до обработки входных данных. А в таком случае контракт означает "наш сервер написан с допущением, что к нему приходят только правильные запросы". Наверное и так можно для какой-то поделки, аля тест или proof of concept, но точно не для real world server.Поэтому получается где-то на отрезке между получением запроса и вызовом пресловутой функции должна быть смена контракта, чтобы real world делился для допустимые и не допустимые запросы с соответствющей обработкой. Ошибка именно в этом, а не в том, что крашится или не крашится в самой функции.
> f(ptr == NULL) {
> // ???
>}По обыкновению exit(-1).
Дальше или пусть сырцы курят или маны дрочат.
А и комент ставить надо - тут пришла не та хрень, продолжаю работать, а хрень по боку. И дату, и подпись.
if(ptr == NULL) {
ptr = default_ptr;
}например
> if(ptr == NULL) {
> ptr = default_ptr;
> }
> напримерsize_t strlen(const char *s) {
if(s == NULL) {
s = ???;
}
// бла-бла-бла
}что надо подставить вместо ???
Это всё фрактал напортил. Поэтому он теперь бегает и кричит про сишные дырени и сам больше ничего не делает.
Если Вы вуцчили 32 ключевых слова языка С, то вы еще не программист. ДАЛЕКО не програмист. Програмист это состояние души а не требования по з/п.