- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
static OSStatus
SSLVerifySignedServerKeyExchange(SSLContext *ctx, bool isRsa, SSLBuffer signedParams,
uint8_t *signature, UInt16 signatureLen)
{
OSStatus err;
...
if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0)
goto fail;
if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
goto fail;
goto fail;
if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)
goto fail;
...
Говно с яблочным привкусом.
http://habrahabr.ru/post/213525/
P.S.: Не уверен Си это или плюсы.
Follow us!
+1
Чтоб наверняка? А точнее, второе гото будет безусловным.
Ну не могут some_hash_update() и some_hash_final() завершиться неудачей. Тупо не могут. Там просто нечему фейлиться (кроме случая, когда через этот хеш прогнали 2^61 байт, который они по-любому забыли проверить). Поэтому никакие коды возврата и исключения тут тупо не нужны.
buf == NULL, size == 0 - все ок, просто ничего не делаем
buf == NULL, size != 0 - аборт() или ассерт(), ибо прога явно косячная, и дальше лучше не продолжать, чтобы не запороть данные
С тем же успехом туда могли передать не нулл а просто мусор.
- оверхед вызова по указателю.
still better than Delphi
Mea culpa, надо было это дописать.
Да и нормальная IDE выдала бы варнинг https://twitter.com/appcode/status/437896886649757696/photo/1
Типичная XCode не выдаёт, проверено (даже при запуске Analyze). GCC 4.8.1 не выдаёт. cppcheck 1.60.1 не выдаёт. clang и clang-check 3.4 не выдают.
> XCode не [...]
где противоречие?
по тому что я читал, то железо оно обламится не может - там тупое I/O. обломится может драйвер на выделении памяти или проверке входных параметров.
Кстати, а в линухе буфера для read/write/ioctl как драйверу передаются? Драйвер получает прямой доступ к реальному буферу в процессе пользователя, или он копируется в ядерную память на write и из ядерной памяти на read?
И первое и второе, но как правило второе. Потому что память процесса может быть свопнута: наивный доступ к памяти процесса чреват последствиями.
Ну понятно, что есть случаи, когда к свопуемой памяти обращаться нельзя ни при каких условиях (тот же драйвер hdd, т.к. на нем может оказаться сам своп, или обработчики прерываний, где надо быстро вернуть управление). Но в общем случае, емнип, ядерная память вполне может своповаться...
В общем случае - как раз таки нет.
В кернеле, есть два типа памяти: kmalloc() vs. vmalloc(). Первое быстрее и есть настоящий кусок непрерывное физической памяти (== диапазон страниц), почему и ограниченый ресурс. Второе медленее, но можно выделять почти без ограничений - но нет гарантии непрерывности физ памяти, для DMA/в обработчике прерываний/этц пользоватся такой памятью нельзя.
Ни первое, ни второе - не свопится. Потому что линухов кернел несвопится.
Для того что бы что-то сваппилось, нужно из под кернела запускать свой спец процесс (то что в top показывается в квадратных скобках) и в этом процессе теперь можно выделять свопаемую память.
Это краткое описание. Гугли kmalloc() и vmalloc() - на гугле лежит много всего.
О как, я про это не знал...
Я думаю что эта байка пошла с времен OS/2 которая позволяла кернел в своп записать (потому что он сидел в обычном сегменте памяти) что многие интерпретировали как "кернел свопнут". Что само собой не соответствует реальности. Если слить на диск драйвер диска и удалить его из памяти, что же его назад из свопа прочитает?
Та же фигня на микро-кернелах. Сами микро-кернела нельзя свопить. И на куче внутренних процессов стоит птичка что их из памяти удалять нельзя - например тот же своппер есть обычный процесс.
Надо будет повтыкать как-нибудь:
http://en.wikipedia.org/wiki/Comparison_of_operating_system_kernels
Не всегда возможно. Для вычисление хэша или какго-нибудь шифрования со сцеплением блоков необходимо получить текущее состояние железки
:))))))))))))))))))))))))))))))))))))))) )
А именно ОБЯЗАТЕЛЬНО ставить операторные скобки. Конечно не панацея, но в разы снижает вероятность всяких проёбов.
Да принудительное форматирование и сейчас вроде как есть.
Что совсем не отменяет тестирования. Особенно в таких ответственных местах.
code review
> из-за них деградирует структурное мышление, ибо мозгу незачем напрягаться
А из-за подсветки синтаксиса вообще наверное весь мозг отмирает за ненадобностью.
То-то я смотрю твой разум как накачанный мускул блять, от таких суровых испытаний, каждый день пишешь неподдерживаемое говно в блокноте без отступов, и посмеиваешься, пока всякие борманды деградируют со своими удобными инструментиками.