Разработчики проекта OpenBSD представили (http://www.mail-archive.com/announce@openbsd.org/msg001...) выпуск переносимой редакции пакета LibreSSL 2.5.2 (http://www.libressl.org/), в рамках которого развивается форк OpenSSL, нацеленный на обеспечение более высокого уровня безопасности. Проект LibreSSL ориентирован на качественную поддержку протоколов SSL/TLS с удалением излишней функциональности, добавлением дополнительных средств защиты и проведением значительной чистки и переработки кодовой базы.
Особенности LibreSSL 2.5.2:
- Добавлена новая функция распределения памяти recallocarray() (http://man.openbsd.org/recallocarray), которая теперь используется вместо reallocarray() в некоторых подсистемах, таких как CBB и BUF_MEM_grow. Новая функция отличается тем, что производит очистку содержимого выделяемых блоков памяти, по аналогии с calloc(), а также обнуляет или отдаёт системе (unmap) не распределённые блоки памяти;- В список корневых сертификатов добавлен сертификат удостоверяющего центра SECOM Trust Systems;
- Добавлена возможность использования интерфейса EVP (https://wiki.openssl.org/index.php/EVP) для хэшей MD5+SHA1;
- Налажена обработка добавочного заполнения при обновлении запроса SSLv2 до соединения SSLv3/TLS;- Для реализаций протоколов и шифров предоставлена возможность установки конфигурационных объёктов TLS в libtls;
- Снижена нагрузка на CPU при согласовании TLS-соединения при использовании утилиты nc.
URL: http://www.mail-archive.com/announce@openbsd.org/msg001...
Новость: https://www.opennet.ru/opennews/art.shtml?num=46259
Шел 2017 год. Сишники до сих пор копаются в своих alloc/calloc/malloc.
> Шел 2017 год. Сишники до сих пор копаются в своих alloc/calloc/malloc.А у них есть выбор?
Удивляет даже, что это вообще упоминается в чейнджлоге новости. Каждый раз переизобретают колёса: в glib разве уже нет специальных функций вроде g_slice_alloc0? А тут это преподносится как инновационное супердостижение.
про "переносимость" не дочитал ?
Где-то есть glibc, а где-то и нет.
Берешь любой опенсорц-проект на си, заглядываешь в исходники -- нет-нет, да и там найдется своя собственная версия super_calloc. Где ж ваша хваленая стандартизация? И эти люди что-то там говорят про left-pad.
а что в super_calloc не используется функция malloc, calloc, free и тд. ?
> И эти люди что-то там говорят про left-pad.Как будто мы этот super_calloc при каждой компиляции с левого сервака качаем.
> про "переносимость" не дочитал ?
> Где-то есть glibc, а где-то и нет.Эм. glibc и glib — как бы разные вещи. Впрочем, обе по-любому не подходят из-за их лицензий...
>> Шел 2017 год. Сишники до сих пор копаются в своих alloc/calloc/malloc.
> А у них есть выбор?Конечно! Десятое правло https://packages.debian.org/source/sid/libgc Гринспена -- решает. </и почту читать>
Шёл уже пятый десяток лет безуспешных попыток создать язык лучше Си...
А правда, что у вас там нет исключений, и вам приходится как обезьянам проверять ошибки непосредственно после вызова какой-либо функции?
Да я и в плюсах не использую исключения -- уж очень у них некрасивый синтаксис на мой вкус.
> Да я и в плюсах не использую исключения -- уж очень у
> них некрасивый синтаксис на мой вкус.В нормальных языках:
try {
return unsafe_op1(unsafe_op2(unsafe_op3()));
} catch (e) {
return fallback();
}В няшной сишке (в режиме "никакого некрасивого синтаксиса"):
int result3;
int error3 = unsafe_op3(&result3);if (error3) {
return fallback();
}int result2;
int error2 = unsafe_op2(result3, &result2);if (error2) {
return fallback();
}int result1;
int error1 = unsafe_op1(result2, &result1);if (error1) {
return fallback();
}return result1;
Для C скорее будет:
int result;result = unsafe_op3();
if (errno)
return fallback();result = unsafe_op2(result);
if (errno)
return fallback();result = unsafe_op1(result);
if (errno)
return fallback();return result;
или
int result;unsafe_op3(&result);
if (errno)
return fallback();unsafe_op2(&result);
if (errno)
return fallback();unsafe_op1(&result);
if (errno)
return fallback();return result;
Обычно приходится видеть что-то типа:
try {
int* array= new int[1000];
}
catch (exception& e) {
cout << "Standard exception: " << e.what() << endl;
return(-1);
}
return 0;
int* array = malloc(1000 * sizeof(int));
if (!array) {
printf("malloc failed\n");
return(-1);
}
return 0;
А errno что, глобальная переменная? Прямо как в старом добром QBASIC.
> А errno что, глобальная переменная?
Во-первых, ЧИТАБЕЛЬНЫЙ вариант на Си выглядит как описано ниже, а не как у вас с кучей лишних строк, фигурных скобок где только возможно и лишних переменных типа error1:
int r1, r2, r3;if (!unsafe_op3(&r3))
goto fallback;if (!unsafe_op2(&r2, r3))
goto fallback;if (!unsafe_op1(&r1, r2))
goto fallback;return r1;
fallback:
return fallback();Во-вторых, сказки не надо рассказывать, какие хорошие эти исключения. В этих ваших C++/Java/Python всё построено на объектах, и во-первых у вас в коде появится вызов конструктора для ваших unsafe_ (а в особо клинических случаях ещё и деструктор ручками вызывать придётся в каких-нибудь finally, при этом следя, чтобы вызывать деструкторы только для переменных, которые были инициализированы успешно), во-вторых если вы получаете исключение, то перед вызовом fallback вам ещё нужно какие-то ресурсы освободить.
Из-за всех этих сложностей 99% ошибок обрабатываются методом "пробрасываем исключение до main(), а там выводим стектрейс в лог и завершаем программу". К чести исключений скажу, что 99% ошибок и невозможно обработать в коде, и вывести ошибку в лог и завершиться - единственный возможный вариант, и механизм исключений оптимизирован именно для этих случаев.
Но в половине, если не больше, реальных приложений, использующих исключения, происходит что-то типа
try
{
file_stream fs;
fs.open();
fs.write();
fs.read();
fs.write();
fs.read();
fs.close();
}
catch (e)
{
// что будет если fs не был закрыт? да не может такого быть, я же написал fs.close() выше
return fallback();
}Не верите мне - почитайте Спольски.
> перед вызовом fallback вам ещё нужно какие-то ресурсы освободитьВ C++, при всех его недостатках, эта проблема легко решается деструкторами (RAII и всё такое), вызов которых только для инициализированных объектов в порядке, обратном порядку их создания, обеспечивается компилятором. И не надо никаких жабских try-with-resources, питоновских "with", шарповских "using" и прочих подобных костылей, призванных компенсировать неопределённость/непредсказуемость момента и порядка уничтожения объектов.
> что будет если fs не был закрыт?
Если автор класса "file_stream" не совсем дурак, то деструктор закроет "fs" ещё до начала выполнения блока "catch" из-за выхода объекта из его области видимости. К.О.
> деструктор закроет "fs" ещё до начала выполнения блока "catch"Главное, не забыть в деструкторе проверить uncaught_exception() на случай, если исключение возникло в close(). А если оно возникло не в close() и полноценный close() выполнить невозможно, то функция снаружи об этом никогда не узнает (справедливости ради, не могу придумать пример, когда вызов полноценного close() был бы необходим при незавершившемся write()).
Проблема в том, что чтобы понять, как в этом случае себя ведёт код, нужно ЗНАТЬ, как работают исключения в конкретном языке (как вы написали, в разных языках есть свои особенности), знать, как РЕАЛИЗОВАН деструктор (вызывает ли он close()) и в каких случаях он вызывается компилятором/средой выполнения. В Си же вся логика локализована в одном месте (в нашей функции) и как оно будет работать можно оттрейсить "глазами".
теоретически - да. В абсолютном большинстве случаев на это можно забить. А в тех, когда нельзя - приходится кроме этого проверять такую тучу нюансов, что урод получается вообще на любом языке.Последние три года я пишу практичсеки только на сях довольно крупную штуку, и уже никких матов нет на отсутствие исключений. Что самое смешное - в go хоть они и есть, но ошибки обрабатываются таким же уродским сопосбом, что и в сях.
RAII хорош, но он решает не все проблемы.Грубо говоря, в языке с исключениями (и особенно — в C++ с его контекстно-зависимой
грамматикой, когда конкретный код, который будет вызван в высказыванииa = b;
зависит от типа a, от того, инициализирована ли эта переменная, а также от типа b),
и потому просто читая код, человеку невозможно понять, в какой именно точке он может взорваться. Проще говоря, в программе на C++ это почти любой сивмол в исходном коде.Посему осмысленный анализ хода выполнения программы становится фактически невозможным,
и это основная причина перехвата большинства исключений в main().Вот тут <http://250bpm.com/blog:4> это всё изложено предельно доступно.
Человек не в курсе, что обработку исключительных ситуаций надо проектировать как часть архитектуры, только и всего. Если что - с квалификацией программиста, особенно тех, кто довольно низкоуровневыми вещами занимается, это обычно не связано. А вот тут - не свезло, судя по всему.Сто раз уже говорил - разные подходы работают на проектах разного размера. Сишный - органичен для не особо крупного софта (во време создания сей, собственно, весь софт таким был), где нет тысяч разных типов данных и миллионов параллельно существующих сущностей. Там работает и errno, и вообще возврат кодов ошибок, и всё это не надо отдельно продумывать.
Когда у вас миллионы строк выгоднее другое. вот те самые ООП, изоляция, проектирование исключительных ситуаций и их обработки, четко формализованные принципы "когда что использовать", правила именования и прочее. И исключения в том числе. Которые сложны сами по себе - потому что и предназначены для сложных систем. Например, половина описанных в посте жалоб решается иерархией исключений - да, для каждой новой ошибки ты создаёшь новый тип, но если он наследует от подходящего родителя отдельного кода обработки это почти не требует - только там, где отличия действительно существенны для обработки.
> Когда у вас миллионы строк выгоднее другое. вот те самые ООП, изоляция,
> проектирование исключительных ситуаций и их обработки, четко формализованные принципы
> "когда что использовать", правила именования и прочее.Самое забавное, что в итоге программы на c++ не меньше по объему кода, а больше. Достаточно вспомнить про qt, boost, ff. Иногда возникает такое чувство, что классы и объекты самостоятельно размножаются :)
И наоборот - есть сложные проекты, написанные на C, которые активно развиваются и при этом остаются менее сложными для развития (linux, blender) за счет грамотной общей архитектуры (разбиение на части/подсистемы/подпроекты).
> Самое забавное, что в итоге программы на c++ не меньше по объему кода, а больше. Достаточно вспомнить про qt, boost, ff. Иногда возникает такое чувство, что классы и объекты самостоятельно размножаются :)А так и есть, на плюсах обертки часто занимают место гораздо больше чем сам код. Как результат - появляются интересные печатные труды на подобие классической монографии "о переливании из пустого в порожнее" Фаулера.
> вам приходится как обезьянам проверять ошибкиПроверка ошибок - это вообще обезьянья работа. Но хипстерам не понять, за них ошибки пользователи ищут.
А ещё мы как обезьяны их обрабатываем - и не всегда завершением работы с выводом в лог стектрейса.
> А правда, что у вас там нет исключений, и вам приходится как
> обезьянам проверять ошибки непосредственно после вызова какой-либо функции?Вообще-то как обезъянам приходится жить Вам и подобным -- вместо делания чего-нить полезного шариться по вражеским форумам и адвокатить в пользу некрософта, по наблюдениям за всем свежеляпнутым с этого адреса. Так шта не проецируйте, лучше человеком наконец становитесь.
> Сишники до сих пор копаются в своих alloc/calloc/mallocВидишь alloc/calloc/malloc в компиляторе/интерпретаторе/виртмашине своего любимого языка? - Нет... - А они там есть!
> Шел 2017 год. Сишники до сих пор копаются в своих alloc/calloc/malloc.Хозяйке на заметку: с этого же адреса будто по методичке "критиковали" (бездарно притом) ODF и адвокасили MSO, ну и баловались вещанием как бы в несколько ников хором.
Призовая ссылка: http://wiki.opennet.ru/MSSP
Что там с nc? Разве оно ещё и SSL умеет?
> Что там с nc? Разве оно ещё и SSL умеет?Сам не умеет, но может использоваться совместно с openssl:
https://en.wikipedia.org/wiki/Netcat#Proxying
socat умеет
> Что там с nc? Разве оно ещё и SSL умеет?В OpenBSD умеет. И он же поставляется в комплекте с LibreSSL.
Интересно, почему DistroWatch заклинило на версии 2.4.5 и он её считает последней и не сообщает о свежих версиях?
> Интересно, почему DistroWatch заклинило на версии 2.4.5 и он её считает последней
> и не сообщает о свежих версиях?Потому что ему никто не помог, очевидно.
DistroWatch вообще не слишком точная площадка, но многие пользуются за неимением лучшего...