forum.opennet.ru - "Обновление DNS-сервера BIND 9.11.22, 9.16.6, 9.17.4 с устранением 5 уязвимостей" (29)

"Обновление DNS-сервера BIND 9.11.22, 9.16.6, 9.17.4 с устранением 5 уязвимостей"

Форум Разговоры, обсуждение новостей
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[ Отслеживать ]

"Обновление DNS-сервера BIND 9.11.22, 9.16.6, 9.17.4 с устранением 5 уязвимостей"	+/–
Сообщение от opennews (??), 21-Авг-20, 11:52
Опубликованы корректирующие обновления стабильных веток 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.dev/opennews/art.shtml?num=53577
Ответить \| Правка \| Cообщить модератору

Оглавление

вот бы на расте писали бы его и небыло, Аноним (1), 11:52 , 21-Авг-20, (1) –10

А где в новости про переполнение буфера, Фракталушка Там билиотека корректно оп, Аноним (2), 12:01 , 21-Авг-20, (2) +3

Решение грохать весь процесс из-за некритичной для работы приложения ошибки -- э, Аноним (3), 12:58 , 21-Авг-20, (3) –1

В расте тоже нет исключений , YAAnonim (?), 14:22 , 21-Авг-20, (4)
Для обработки ошибок не всегда нужны исключения Но обработчики ошибок надо же п, Аноним (7), 14:32 , 21-Авг-20, (7) +1

Докажешь что не задумываясь Я вот вижу что обмозговали и поставили assert PS А, _ (??), 17:21 , 21-Авг-20, (16)
Это не была обработка ошибок Ассерт в данном случае использован совершенно корр, Webmonkey (?), 20:12 , 21-Авг-20, (27)

Вы писали бы его на расте -- его и нет, что характерно , Michael Shigorin (ok), 14:28 , 21-Авг-20, (5) –4
На расте бы это никогда не написали Да и не напишут Рас это такие розовые очки , Аноним (9), 15:53 , 21-Авг-20, (9) +2

Rust просто неадекватно переусложнён Хеллоуворлды на нём выглядят красиво, а ка, НяшМяш (ok), 16:32 , 21-Авг-20, (13) –1

Пиши на Ziglang, Аноним (30), 20:50 , 21-Авг-20, (30)

Напиши, а после удали и раст заодно тоже, microsoft (?), 20:40 , 21-Авг-20, (28)

Подход долбанов, вместо обработки даже самых простых ошибок сразу крашить прилож, Аноним (7), 14:30 , 21-Авг-20, (6) –1

Подход долбанов -- это когда опыта нет, а мнение есть Тебе не приходилось сталк, Ordu (ok), 15:54 , 21-Авг-20, (10) +6

Зачёт, нравится читать когда осмысленно пишут и со знанием дела , Аноним (9), 16:21 , 21-Авг-20, (11) +1
Если контракт нарушен программистом id est контролируемым источником , крашитьс, Аноним (3), 16:28 , 21-Авг-20, (12) +1

Крешиться или нет это вопрос критичности участка кода Если ситуация такая, что , Sw00p aka Jerom (?), 22:18 , 21-Авг-20, (31)

Если тебе по сети пришел неправильный пакет, ты это обнаружил и уронил все, вмес, Аноним (7), 17:11 , 21-Авг-20, (14)

Ты не думал, что эти ситуации могут жить совместно Пришёл неправильный пакет, ты, Ordu (ok), 17:44 , 21-Авг-20, (21) –3

Если быть более точным, функция, которой ты воспользовался, вернула NULL Смотри, Аноним (3), 17:49 , 21-Авг-20, (24) +1

Вот, вот Нулл всегда можно обработать если есть эдакий контракт , Sw00p aka Jerom (?), 22:29 , 21-Авг-20, (32)

И в коментах ниже каждый смотри с разного уровня Кто сверху в низ, кто с низу в, Аноним (9), 17:20 , 21-Авг-20, (15)

Я - прав By definition C -p, _ (??), 17:42 , 21-Авг-20, (20)

Всё верно Фактически assert это своего рода документирование контракта Т е пре, Аноним (29), 20:49 , 21-Авг-20, (29)
По обыкновению exit -1 Дальше или пусть сырцы курят или маны дрочат А и комент, Аноним (33), 06:12 , 24-Авг-20, (33) +1
if ptr NULL ptr default_ptr например, я (?), 11:30 , 28-Авг-20, (35)

size_t strlen const char s if s NULL s бла, Ordu (ok), 12:24 , 28-Авг-20, (36)

Это всё фрактал напортил Поэтому он теперь бегает и кричит про сишные дырени и , Аноним (9), 15:52 , 21-Авг-20, (8) +1

Если Вы вуцчили 32 ключевых слова языка С, то вы еще не программист ДАЛЕКО не п, Аноним (33), 06:13 , 24-Авг-20, (34)

Сообщения [Сортировка по ответам | RSS]

1. Сообщение от Аноним (1), 21-Авг-20, 11:52 –10 +/–

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

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #2, #5, #9, #28

2. Сообщение от Аноним (2), 21-Авг-20, 12:01 +3 +/–

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #3

3. Сообщение от Аноним (3), 21-Авг-20, 12:58 –1 +/–

> она решает корректно завершиться
Решение грохать весь процесс из-за некритичной для работы приложения ошибки -- это именно си-стайл-решение. Оно и понятно, ведь все ошибки надо обрабатывать прямо здесь и прямо сейчас, а такой штуки, как исключения, в си нету. А потому ничего не остается, кроме как тупо завершиться.
Это как если бы ты увидел в этом предложении очепяткуAssertion error: unknown word "очепятку"

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #4, #7

4. Сообщение от YAAnonim (?), 21-Авг-20, 14:22 +/–

В расте тоже нет исключений.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3

5. Сообщение от Michael Shigorin (ok), 21-Авг-20, 14:28 –4 +/–

Вы "писали бы его" на расте -- его и нет, что характерно...

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

6. Сообщение от Аноним (7), 21-Авг-20, 14:30 –1 +/–

Подход долбанов, вместо обработки даже самых простых ошибок сразу крашить приложение

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #10

7. Сообщение от Аноним (7), 21-Авг-20, 14:32 +1 +/–

Для обработки ошибок не всегда нужны исключения. Но обработчики ошибок надо же писать, проще просто написать assert не задумываясь о последствиях

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #16, #27

8. Сообщение от Аноним (9), 21-Авг-20, 15:52 +1 +/–

Это всё фрактал напортил. Поэтому он теперь бегает и кричит про сишные дырени и сам больше ничего не делает.

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #34

9. Сообщение от Аноним (9), 21-Авг-20, 15:53 +2 +/–

На расте бы это никогда не написали. Да и не напишут.
Рас это такие розовые очки. "Вот иесли бы да кабы..." но так сказкой и остаётся.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #13

10. Сообщение от Ordu (ok), 21-Авг-20, 15:54 +6 +/–

Подход долбанов -- это когда опыта нет, а мнение есть. Тебе не приходилось сталкиваться с ситуацией, когда в твою функцию через аргументы закидывают указатель, и ты в документации к ней написал, что указатель должен быть !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.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #11, #12, #14, #15, #29, #33, #35

11. Сообщение от Аноним (9), 21-Авг-20, 16:21 +1 +/–

Зачёт, нравится читать когда осмысленно пишут и со знанием дела.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10

12. Сообщение от Аноним (3), 21-Авг-20, 16:28 +1 +/–

> кто-то зачем-то засунул тебе NULL туда, куда NULL пихать нельзя
Если контракт нарушен программистом (id est контролируемым источником), крашиться не только можно, но и нужно. Так быстрее обнаружим ошибку. В некоторых языках твои нуллы отловятся еще на этапе компиляции, так что не получится даже запуститься, чтобы закрашиться.
Если контракт нарушен пользователем (id est неконтролируемым источником), крашиться нельзя.
Если на ноль делит программист непосредственно в исходниках -- крашимся. Если делит на ноль пользователь в гуйном калькуляторе -- не крашимся и показываем ошибку. Отличаешь ситуации? В новости именно второй вариант.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #31

13. Сообщение от НяшМяш (ok), 21-Авг-20, 16:32 –1 +/–

Rust просто неадекватно переусложнён. Хеллоуворлды на нём выглядят красиво, а как что-то сложнее - так даже глаза за символы зацепиться не могут.
А так DNS сервера даже на JS бывают https://www.npmjs.com/search?q=dns%20server

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9 Ответы: #30

14. Сообщение от Аноним (7), 21-Авг-20, 17:11 +/–

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #21

15. Сообщение от Аноним (9), 21-Авг-20, 17:20 +/–

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #20

16. Сообщение от _ (??), 21-Авг-20, 17:21 +/–

Докажешь что не задумываясь?
Я вот вижу что обмозговали и поставили assert.
PS: А не с жЫсЫ проггером ли я спорю? Пойду руки помою на всякий ...

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7

20. Сообщение от _ (??), 21-Авг-20, 17:42 +/–

Я - прав. By definition (C) ;-p

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15

21. Сообщение от Ordu (ok), 21-Авг-20, 17:44 –3 +/–

> Если тебе по сети пришел неправильный пакет, ты это обнаружил и уронил
> все, вместо того чтобы:
> отбросить пакет, записать в лог о наличии неправильного пакета. Но долбаны предпочитают
> крашить.
> Ситуация с NULL поинтереснее, если есть возможность вернут ошибку выше - то
> лучше вернуть ошибку, а не уронить все сразу. Если нет возможности
> вернуть ошибки, значит тут выхода больше нет.
Ты не думал, что эти ситуации могут жить совместно?
Пришёл неправильный пакет, ты это обнаружил, но лишь по косвенным признакам: тебе прилетел NULL туда, куда не должен прилетать. Что ты будешь делать?
Ну, точнее не так, это не ты обнаружил неправильный пакет, всё что ты обнаружил, что твоя программа иногда получает NULL там, где его не должно быть. Копая глубже, ты выяснил, что в процессе разборки запроса был упущен какой-то вариант кривости запроса, и вместо генерации ошибки, была сгенерирована кривая структура, описывающая этот запрос. Кривая структура ушла дальше на выполнение, и там вдруг образовался NULL в переменной, которая NotNULL. Но все эти копания произошли позже, уже после того как программа упала. А упасть она смогла, вместо выхода за границы массива, благодаря тому, что ты поставил assert в том месте, где по идее не могло быть NULL, или len>=size, или ещё чего-нибудь. Ты не видел как такое может случится, ты не знал как реагировать на то, что на твой взгляд не может случится, но на всякий случай подстраховался assert'ом.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14 Ответы: #24

24. Сообщение от Аноним (3), 21-Авг-20, 17:49 +1 +/–

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21 Ответы: #32

27. Сообщение от Webmonkey (?), 21-Авг-20, 20:12 +/–

Это не была обработка ошибок. Ассерт в данном случае использован совершенно корректно для проверки инварианта.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7

28. Сообщение от microsoft (?), 21-Авг-20, 20:40 +/–

Напиши, а после удали и раст заодно тоже

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

29. Сообщение от Аноним (29), 21-Авг-20, 20:49 +/–

Всё верно!
Фактически assert это своего рода документирование контракта. Т.е. предполагается, что дальнейший код написан с учетом этого допущения, т.е. что ptr != NULL.
Но это не значит, что он не мог быть написан иначе, просто такой контракт.
Далее вызывающая сторона должна что-то с этим решать, т.е. либо обеспечить этот контакт самостоятельно или "экспортировать" контракт выше.
Как видно, в данном случае контракт, что условный ptr != NULL был экспортирован вплоть до обработки входных данных. А в таком случае контракт означает "наш сервер написан с допущением, что к нему приходят только правильные запросы". Наверное и так можно для какой-то поделки, аля тест или proof of concept, но точно не для real world server.
Поэтому получается где-то на отрезке между получением запроса и вызовом пресловутой функции должна быть смена контракта, чтобы real world делился для допустимые и не допустимые запросы с соответствющей обработкой. Ошибка именно в этом, а не в том, что крашится или не крашится в самой функции.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10

30. Сообщение от Аноним (30), 21-Авг-20, 20:50 +/–

Пиши на Ziglang

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13

31. Сообщение от Sw00p aka Jerom (?), 21-Авг-20, 22:18 +/–

Крешиться или нет это вопрос критичности участка кода. Если ситуация такая, что дальнейщее исполнение алгоритма теряет смысл, то останавливаем исполнение. Крах и немедленная остановка процесса исполнения - разные вещи.
>Если на ноль делит программист непосредственно в исходниках -- крашимся.
Это должен отловить компилятор, как тоже самое отлавливает ЦПУ или рантайм любого языка. И собственно происходит выброс исключения которое можно обработать.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12

32. Сообщение от Sw00p aka Jerom (?), 21-Авг-20, 22:29 +/–

Вот, вот. Нулл всегда можно обработать если есть эдакий "контракт".

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24

33. Сообщение от Аноним (33), 24-Авг-20, 06:12 +1 +/–

> f(ptr == NULL) {
>    // ???
>}
По обыкновению exit(-1).
Дальше или пусть сырцы курят или маны дрочат.
А и комент ставить надо - тут пришла не та хрень, продолжаю работать, а хрень по боку. И дату, и подпись.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10

34. Сообщение от Аноним (33), 24-Авг-20, 06:13 +/–

Если Вы вуцчили 32 ключевых слова языка С, то вы еще не программист. ДАЛЕКО не програмист. Програмист это состояние души а не требования по з/п.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8

35. Сообщение от я (?), 28-Авг-20, 11:30 +/–

if(ptr == NULL) {
ptr = default_ptr;
}
например

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #36

36. Сообщение от Ordu (ok), 28-Авг-20, 12:24 +/–

> if(ptr == NULL) {
>  ptr = default_ptr;
> }
> например
size_t strlen(const char *s) {
    if(s == NULL) {
        s = ???;
    }
    // бла-бла-бла
}
что надо подставить вместо ???

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2025 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. Сообщение от Аноним (1), 21-Авг-20, 11:52	–10 +/–
вот бы на расте писали бы его и небыло
Ответить \| Правка \| Наверх \| Cообщить модератору
Ответы: #2, #5, #9, #28

2. Сообщение от Аноним (2), 21-Авг-20, 12:01	+3 +/–
А где в новости про переполнение буфера, Фракталушка? Там билиотека корректно определяет размер, а проге большие пакеты не нравятся и она решает корректно завершиться. Т.е. проблема в алгоритмах, от чего Ржавый не спасёт.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #1 Ответы: #3

3. Сообщение от Аноним (3), 21-Авг-20, 12:58	–1 +/–
> она решает корректно завершиться Решение грохать весь процесс из-за некритичной для работы приложения ошибки -- это именно си-стайл-решение. Оно и понятно, ведь все ошибки надо обрабатывать прямо здесь и прямо сейчас, а такой штуки, как исключения, в си нету. А потому ничего не остается, кроме как тупо завершиться. Это как если бы ты увидел в этом предложении очепяткуAssertion error: unknown word "очепятку"
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #2 Ответы: #4, #7

4. Сообщение от YAAnonim (?), 21-Авг-20, 14:22	+/–
В расте тоже нет исключений.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #3

5. Сообщение от Michael Shigorin (ok), 21-Авг-20, 14:28	–4 +/–
Вы "писали бы его" на расте -- его и нет, что характерно...
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #1

6. Сообщение от Аноним (7), 21-Авг-20, 14:30	–1 +/–
Подход долбанов, вместо обработки даже самых простых ошибок сразу крашить приложение
Ответить \| Правка \| Наверх \| Cообщить модератору
Ответы: #10

7. Сообщение от Аноним (7), 21-Авг-20, 14:32	+1 +/–
Для обработки ошибок не всегда нужны исключения. Но обработчики ошибок надо же писать, проще просто написать assert не задумываясь о последствиях
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #3 Ответы: #16, #27

8. Сообщение от Аноним (9), 21-Авг-20, 15:52	+1 +/–
Это всё фрактал напортил. Поэтому он теперь бегает и кричит про сишные дырени и сам больше ничего не делает.
Ответить \| Правка \| Наверх \| Cообщить модератору
Ответы: #34

9. Сообщение от Аноним (9), 21-Авг-20, 15:53	+2 +/–
На расте бы это никогда не написали. Да и не напишут. Рас это такие розовые очки. "Вот иесли бы да кабы..." но так сказкой и остаётся.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #1 Ответы: #13

10. Сообщение от Ordu (ok), 21-Авг-20, 15:54	+6 +/–
Подход долбанов -- это когда опыта нет, а мнение есть. Тебе не приходилось сталкиваться с ситуацией, когда в твою функцию через аргументы закидывают указатель, и ты в документации к ней написал, что указатель должен быть !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.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #6 Ответы: #11, #12, #14, #15, #29, #33, #35

11. Сообщение от Аноним (9), 21-Авг-20, 16:21	+1 +/–
Зачёт, нравится читать когда осмысленно пишут и со знанием дела.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #10

12. Сообщение от Аноним (3), 21-Авг-20, 16:28	+1 +/–
> кто-то зачем-то засунул тебе NULL туда, куда NULL пихать нельзя Если контракт нарушен программистом (id est контролируемым источником), крашиться не только можно, но и нужно. Так быстрее обнаружим ошибку. В некоторых языках твои нуллы отловятся еще на этапе компиляции, так что не получится даже запуститься, чтобы закрашиться. Если контракт нарушен пользователем (id est неконтролируемым источником), крашиться нельзя. Если на ноль делит программист непосредственно в исходниках -- крашимся. Если делит на ноль пользователь в гуйном калькуляторе -- не крашимся и показываем ошибку. Отличаешь ситуации? В новости именно второй вариант.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #10 Ответы: #31

13. Сообщение от НяшМяш (ok), 21-Авг-20, 16:32	–1 +/–
Rust просто неадекватно переусложнён. Хеллоуворлды на нём выглядят красиво, а как что-то сложнее - так даже глаза за символы зацепиться не могут. А так DNS сервера даже на JS бывают https://www.npmjs.com/search?q=dns%20server
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #9 Ответы: #30

14. Сообщение от Аноним (7), 21-Авг-20, 17:11	+/–
Если тебе по сети пришел неправильный пакет, ты это обнаружил и уронил все, вместо того чтобы: отбросить пакет, записать в лог о наличии неправильного пакета. Но долбаны предпочитают крашить. Ситуация с NULL поинтереснее, если есть возможность вернут ошибку выше - то лучше вернуть ошибку, а не уронить все сразу. Если нет возможности вернуть ошибки, значит тут выхода больше нет.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #10 Ответы: #21

15. Сообщение от Аноним (9), 21-Авг-20, 17:20	+/–
И в коментах ниже каждый смотри с разного уровня. Кто сверху в низ, кто с низу в верх. И каждый пытается конкретный случай притощить как универсальное решение. Ребята вы все правы.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #10 Ответы: #20

16. Сообщение от _ (??), 21-Авг-20, 17:21	+/–
Докажешь что не задумываясь? Я вот вижу что обмозговали и поставили assert. PS: А не с жЫсЫ проггером ли я спорю? Пойду руки помою на всякий ...
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #7

20. Сообщение от _ (??), 21-Авг-20, 17:42	+/–
Я - прав. By definition (C) ;-p
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #15

21. Сообщение от Ordu (ok), 21-Авг-20, 17:44	–3 +/–
> Если тебе по сети пришел неправильный пакет, ты это обнаружил и уронил > все, вместо того чтобы: > отбросить пакет, записать в лог о наличии неправильного пакета. Но долбаны предпочитают > крашить. > Ситуация с NULL поинтереснее, если есть возможность вернут ошибку выше - то > лучше вернуть ошибку, а не уронить все сразу. Если нет возможности > вернуть ошибки, значит тут выхода больше нет. Ты не думал, что эти ситуации могут жить совместно? Пришёл неправильный пакет, ты это обнаружил, но лишь по косвенным признакам: тебе прилетел NULL туда, куда не должен прилетать. Что ты будешь делать? Ну, точнее не так, это не ты обнаружил неправильный пакет, всё что ты обнаружил, что твоя программа иногда получает NULL там, где его не должно быть. Копая глубже, ты выяснил, что в процессе разборки запроса был упущен какой-то вариант кривости запроса, и вместо генерации ошибки, была сгенерирована кривая структура, описывающая этот запрос. Кривая структура ушла дальше на выполнение, и там вдруг образовался NULL в переменной, которая NotNULL. Но все эти копания произошли позже, уже после того как программа упала. А упасть она смогла, вместо выхода за границы массива, благодаря тому, что ты поставил assert в том месте, где по идее не могло быть NULL, или len>=size, или ещё чего-нибудь. Ты не видел как такое может случится, ты не знал как реагировать на то, что на твой взгляд не может случится, но на всякий случай подстраховался assert'ом.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #14 Ответы: #24

24. Сообщение от Аноним (3), 21-Авг-20, 17:49	+1 +/–
> программа иногда получает NULL там, где его не должно быть Если быть более точным, функция, которой ты воспользовался, вернула NULL. Смотришь в доки -- да, говорится, что может вернуть NULL. Ты отличаешь NULL, который тебе передали в аргументах в нарушение контракта, от нулла, который ты получил сам, вызвав nullable-функцию?
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #21 Ответы: #32

27. Сообщение от Webmonkey (?), 21-Авг-20, 20:12	+/–
Это не была обработка ошибок. Ассерт в данном случае использован совершенно корректно для проверки инварианта.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #7

28. Сообщение от microsoft (?), 21-Авг-20, 20:40	+/–
Напиши, а после удали и раст заодно тоже
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #1

29. Сообщение от Аноним (29), 21-Авг-20, 20:49	+/–
Всё верно! Фактически assert это своего рода документирование контракта. Т.е. предполагается, что дальнейший код написан с учетом этого допущения, т.е. что ptr != NULL. Но это не значит, что он не мог быть написан иначе, просто такой контракт. Далее вызывающая сторона должна что-то с этим решать, т.е. либо обеспечить этот контакт самостоятельно или "экспортировать" контракт выше. Как видно, в данном случае контракт, что условный ptr != NULL был экспортирован вплоть до обработки входных данных. А в таком случае контракт означает "наш сервер написан с допущением, что к нему приходят только правильные запросы". Наверное и так можно для какой-то поделки, аля тест или proof of concept, но точно не для real world server. Поэтому получается где-то на отрезке между получением запроса и вызовом пресловутой функции должна быть смена контракта, чтобы real world делился для допустимые и не допустимые запросы с соответствющей обработкой. Ошибка именно в этом, а не в том, что крашится или не крашится в самой функции.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #10

30. Сообщение от Аноним (30), 21-Авг-20, 20:50	+/–
Пиши на Ziglang
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #13

31. Сообщение от Sw00p aka Jerom (?), 21-Авг-20, 22:18	+/–
Крешиться или нет это вопрос критичности участка кода. Если ситуация такая, что дальнейщее исполнение алгоритма теряет смысл, то останавливаем исполнение. Крах и немедленная остановка процесса исполнения - разные вещи. >Если на ноль делит программист непосредственно в исходниках -- крашимся. Это должен отловить компилятор, как тоже самое отлавливает ЦПУ или рантайм любого языка. И собственно происходит выброс исключения которое можно обработать.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #12

32. Сообщение от Sw00p aka Jerom (?), 21-Авг-20, 22:29	+/–
Вот, вот. Нулл всегда можно обработать если есть эдакий "контракт".
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #24

33. Сообщение от Аноним (33), 24-Авг-20, 06:12	+1 +/–
> f(ptr == NULL) { > // ??? >} По обыкновению exit(-1). Дальше или пусть сырцы курят или маны дрочат. А и комент ставить надо - тут пришла не та хрень, продолжаю работать, а хрень по боку. И дату, и подпись.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #10

34. Сообщение от Аноним (33), 24-Авг-20, 06:13	+/–
Если Вы вуцчили 32 ключевых слова языка С, то вы еще не программист. ДАЛЕКО не програмист. Програмист это состояние души а не требования по з/п.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #8

35. Сообщение от я (?), 28-Авг-20, 11:30	+/–
if(ptr == NULL) { ptr = default_ptr; } например
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #10 Ответы: #36

36. Сообщение от Ordu (ok), 28-Авг-20, 12:24	+/–
> if(ptr == NULL) { > ptr = default_ptr; > } > например size_t strlen(const char *s) { if(s == NULL) { s = ???; } // бла-бла-бла } что надо подставить вместо ???
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #35