| |
| 2.2, Аноним (2), 12:01, 21/08/2020 [^] [^^] [^^^] [ответить]
| +3 +/– |
А где в новости про переполнение буфера, Фракталушка? Там билиотека корректно определяет размер, а проге большие пакеты не нравятся и она решает корректно завершиться. Т.е. проблема в алгоритмах, от чего Ржавый не спасёт.
| | |
| |
| 3.3, Аноним (3), 12:58, 21/08/2020 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> она решает корректно завершиться
Решение грохать весь процесс из-за некритичной для работы приложения ошибки -- это именно си-стайл-решение. Оно и понятно, ведь все ошибки надо обрабатывать прямо здесь и прямо сейчас, а такой штуки, как исключения, в си нету. А потому ничего не остается, кроме как тупо завершиться.
Это как если бы ты увидел в этом предложении очепяткуAssertion error: unknown word "очепятку"
| | |
| |
| 4.7, Аноним (7), 14:32, 21/08/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
Для обработки ошибок не всегда нужны исключения. Но обработчики ошибок надо же писать, проще просто написать assert не задумываясь о последствиях
| | |
| |
| 5.16, _ (??), 17:21, 21/08/2020 [^] [^^] [^^^] [ответить]
| +/– |
Докажешь что не задумываясь?
Я вот вижу что обмозговали и поставили assert.
PS: А не с жЫсЫ проггером ли я спорю? Пойду руки помою на всякий ...
| | |
| 5.27, Webmonkey (?), 20:12, 21/08/2020 [^] [^^] [^^^] [ответить]
| +/– |
Это не была обработка ошибок. Ассерт в данном случае использован совершенно корректно для проверки инварианта.
| | |
|
|
|
| 2.9, Аноним (9), 15:53, 21/08/2020 [^] [^^] [^^^] [ответить]
| +2 +/– | |
На расте бы это никогда не написали. Да и не напишут.
Рас это такие розовые очки. "Вот иесли бы да кабы..." но так сказкой и остаётся.
| | |
|
| 1.6, Аноним (7), 14:30, 21/08/2020 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
Подход долбанов, вместо обработки даже самых простых ошибок сразу крашить приложение
| | |
| |
| 2.10, Ordu (ok), 15:54, 21/08/2020 [^] [^^] [^^^] [ответить]
| +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.
| | |
| |
| 3.11, Аноним (9), 16:21, 21/08/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
Зачёт, нравится читать когда осмысленно пишут и со знанием дела.
| | |
| 3.12, Аноним (3), 16:28, 21/08/2020 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> кто-то зачем-то засунул тебе NULL туда, куда NULL пихать нельзя
Если контракт нарушен программистом (id est контролируемым источником), крашиться не только можно, но и нужно. Так быстрее обнаружим ошибку. В некоторых языках твои нуллы отловятся еще на этапе компиляции, так что не получится даже запуститься, чтобы закрашиться.
Если контракт нарушен пользователем (id est неконтролируемым источником), крашиться нельзя.
Если на ноль делит программист непосредственно в исходниках -- крашимся. Если делит на ноль пользователь в гуйном калькуляторе -- не крашимся и показываем ошибку. Отличаешь ситуации? В новости именно второй вариант.
| | |
| |
| 4.31, Sw00p aka Jerom (?), 22:18, 21/08/2020 [^] [^^] [^^^] [ответить]
| +/– | |
Крешиться или нет это вопрос критичности участка кода. Если ситуация такая, что дальнейщее исполнение алгоритма теряет смысл, то останавливаем исполнение. Крах и немедленная остановка процесса исполнения - разные вещи.
>Если на ноль делит программист непосредственно в исходниках -- крашимся.
Это должен отловить компилятор, как тоже самое отлавливает ЦПУ или рантайм любого языка. И собственно происходит выброс исключения которое можно обработать.
| | |
|
| 3.14, Аноним (7), 17:11, 21/08/2020 [^] [^^] [^^^] [ответить]
| +/– |
Если тебе по сети пришел неправильный пакет, ты это обнаружил и уронил все, вместо того чтобы:
отбросить пакет, записать в лог о наличии неправильного пакета. Но долбаны предпочитают крашить.
Ситуация с NULL поинтереснее, если есть возможность вернут ошибку выше - то лучше вернуть ошибку, а не уронить все сразу. Если нет возможности вернуть ошибки, значит тут выхода больше нет.
| | |
| |
| 4.21, Ordu (ok), 17:44, 21/08/2020 [^] [^^] [^^^] [ответить]
| –3 +/– |
> Если тебе по сети пришел неправильный пакет, ты это обнаружил и уронил
> все, вместо того чтобы:
> отбросить пакет, записать в лог о наличии неправильного пакета. Но долбаны предпочитают
> крашить.
> Ситуация с NULL поинтереснее, если есть возможность вернут ошибку выше - то
> лучше вернуть ошибку, а не уронить все сразу. Если нет возможности
> вернуть ошибки, значит тут выхода больше нет.
Ты не думал, что эти ситуации могут жить совместно?
Пришёл неправильный пакет, ты это обнаружил, но лишь по косвенным признакам: тебе прилетел NULL туда, куда не должен прилетать. Что ты будешь делать?
Ну, точнее не так, это не ты обнаружил неправильный пакет, всё что ты обнаружил, что твоя программа иногда получает NULL там, где его не должно быть. Копая глубже, ты выяснил, что в процессе разборки запроса был упущен какой-то вариант кривости запроса, и вместо генерации ошибки, была сгенерирована кривая структура, описывающая этот запрос. Кривая структура ушла дальше на выполнение, и там вдруг образовался NULL в переменной, которая NotNULL. Но все эти копания произошли позже, уже после того как программа упала. А упасть она смогла, вместо выхода за границы массива, благодаря тому, что ты поставил assert в том месте, где по идее не могло быть NULL, или len>=size, или ещё чего-нибудь. Ты не видел как такое может случится, ты не знал как реагировать на то, что на твой взгляд не может случится, но на всякий случай подстраховался assert'ом.
| | |
| |
| 5.24, Аноним (3), 17:49, 21/08/2020 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> программа иногда получает NULL там, где его не должно быть
Если быть более точным, функция, которой ты воспользовался, вернула NULL. Смотришь в доки -- да, говорится, что может вернуть NULL. Ты отличаешь NULL, который тебе передали в аргументах в нарушение контракта, от нулла, который ты получил сам, вызвав nullable-функцию?
| | |
|
|
| 3.15, Аноним (9), 17:20, 21/08/2020 [^] [^^] [^^^] [ответить]
| +/– | |
И в коментах ниже каждый смотри с разного уровня. Кто сверху в низ, кто с низу в верх. И каждый пытается конкретный случай притощить как универсальное решение.
Ребята вы все правы.
| | |
| 3.29, Аноним (29), 20:49, 21/08/2020 [^] [^^] [^^^] [ответить]
| +/– |
Всё верно!
Фактически assert это своего рода документирование контракта. Т.е. предполагается, что дальнейший код написан с учетом этого допущения, т.е. что ptr != NULL.
Но это не значит, что он не мог быть написан иначе, просто такой контракт.
Далее вызывающая сторона должна что-то с этим решать, т.е. либо обеспечить этот контакт самостоятельно или "экспортировать" контракт выше.
Как видно, в данном случае контракт, что условный ptr != NULL был экспортирован вплоть до обработки входных данных. А в таком случае контракт означает "наш сервер написан с допущением, что к нему приходят только правильные запросы". Наверное и так можно для какой-то поделки, аля тест или proof of concept, но точно не для real world server.
Поэтому получается где-то на отрезке между получением запроса и вызовом пресловутой функции должна быть смена контракта, чтобы real world делился для допустимые и не допустимые запросы с соответствющей обработкой. Ошибка именно в этом, а не в том, что крашится или не крашится в самой функции.
| | |
| 3.33, Аноним (33), 06:12, 24/08/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
> f(ptr == NULL) {
> // ???
>}
По обыкновению exit(-1).
Дальше или пусть сырцы курят или маны дрочат.
А и комент ставить надо - тут пришла не та хрень, продолжаю работать, а хрень по боку. И дату, и подпись.
| | |
| 3.35, я (?), 11:30, 28/08/2020 [^] [^^] [^^^] [ответить]
| +/– |
if(ptr == NULL) {
ptr = default_ptr;
}
например
| | |
| |
| 4.36, Ordu (ok), 12:24, 28/08/2020 [^] [^^] [^^^] [ответить]
| +/– |
> if(ptr == NULL) {
> ptr = default_ptr;
> }
> например
size_t strlen(const char *s) {
if(s == NULL) {
s = ???;
}
// бла-бла-бла
}
что надо подставить вместо ???
| | |
|
|
|
| 1.8, Аноним (9), 15:52, 21/08/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
Это всё фрактал напортил. Поэтому он теперь бегает и кричит про сишные дырени и сам больше ничего не делает.
| | |
| |
| 2.34, Аноним (33), 06:13, 24/08/2020 [^] [^^] [^^^] [ответить]
| +/– |
Если Вы вуцчили 32 ключевых слова языка С, то вы еще не программист. ДАЛЕКО не програмист. Програмист это состояние души а не требования по з/п.
| | |
|
|
