Хабр Курсы для бэкендеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Бэкенд доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 149
Автор, а вы уже перестали пить коньяк по утрам?
Заголовок кривоват. Проблема не в самих библиотеках, а в документации к ним и сопровождении. К самим библиотекам у вас претензий нет.
к опенссл - есть. Там всё плохо. Но в статье речь не об этом
Судя по вашим комментариям вы даже не пытались разобраться в openssl. Там много чего плохого есть, это правда, но ваши придирки вообще ни о чем.
CMAKELISTS.TXT
Почему не meson.build? Или там conanfile.py? Или premake5.lua? Или... Да тысячи их) И все одна другой краше. Я напомню, что библиотека старше их всех.
Документация у библиотеки есть и довольно обширная:
https://docs.openssl.org/3.0/man1/openssl/
Там и выбор версий, и примеры, и все концепции расписаны. Начиная с 3.0 - так ещё и API поправили, завернув практически все в EVP_XXX вызовы.
И нет, openssl - это не просто "переложить байты". Там комплектом идёт швейцарский нож в виде утилиты openssl, у которой опций столько, что вы читать будете месяцами.
Переписывать это все никто не будет. Библиотека прошла два независимых аудита, а также есть версия сертифицированная FIPS.
я, конечно, давно на Си не писал, могу многое не помнить, но мне кажется, проблема в величине таких библиотек, мало того, что в Си так просто не изменишь уже написанное, много что привязано побайтово, так еще и много что делалось с излишними частями которые должны были использоваться для удобство расширения, а потом, когда от чего то отказались, остались рудименты, которые просто стремно вырезать, мало ли сломается все
Openssl через autotools собирается. Я не понимаю бессмысленной и беспощадной любви к cmake. Это никакой не "основной стандарт сборки приложений c/c++“, а лично мне он вообще не нравится.
Doom сложно, а openssl так, пару байтов местами поменять? Ну-ну.
Ну ка как autotools на windows у нас работают? А откуда зависимости нужные опенссл берутся?
Не все библиотеки одинаково удобно разрабатывать под разные платформы. А если задача только собрать, то есть там перл скрипт, который все сделает.
Не все библиотеки одинаково удобно разрабатывать под разные платформы
задача библиотеки переложить байты, там функционально ничего сложнее memcpy не нужно для работы. А потом оказывается, что без задействования всей ОС не собирается. В общем-то об этом и речь в статье
memcpy — тоже системная функция, которую реализовывает ОС.
И да, для криптографических библиотек ещё нужны всякие системные фишки, вроде RtlSecureZeroMemory().
memcpy это то что идёт в стандартной библиотеке С и её можно написать в 2 строки, просто будет не так оптимально (хотя компилятор может оптимизировать в memcpy)
показываю реализацию RtlSecureZeroMemory :
[[gnu::noinline]] void RtlSecureZeroMemory(void* ptr, size_t size) {
memset(ptr, 0, size);
}
Не знаю, как именно работает gnu::noinline, но по идее нужно гарантировать, что компилятор не будет пытаться не только инлайнить, но и как бы то ни было оптимизировать этот вызов. Иначе же опять повыкидывает нафиг все вызовы перед окончанием лайфтаймов, и никакого "Secure" не будет.
[[gnu::noinline]] и как это будет работать по мсвц? Из-за поддержки зоопарка компиляторов оно всё и усложняется
задача библиотеки переложить байты
Это ровно про 100% программ для Фон-Неймановской архитектуры. А задача openssl раскидывать эти байты быстро, надёжно, секьюрно (хотя бы с точки зрения отсутствия в памяти следов каких-либо секретов), под разные платформы и даже архитектуры. Отсюда да, задействование некоторых тонкостей ОС как бы и неизбежно.
Сборка на любителя, окей. Но вот смотрите, есть отдельный репозиторий для обеспечения cmake сборки. Сравните количество звёзд. Вещь не всем нужная, однозначно.
И одинаково. С одинаковым. предсказуемым набором зависимостей и результатом.
Вот про "одинаково" любители cmake вечно забывают. autotools заботится о том, чтобы быть рабочим на всех архитектурах. У cmake никогда не было такой цели. И запилить кросс-компиляцию на configure && make гораздо проще, чем на смузёвом cmake.
А задача openssl раскидывать эти байты быстро, надёжно, секьюрно
нет задач отрисовки, отправки, работы с файлами даже не нужно, а вот это "быстро секьюрно" это выдумки. Секьюрно они блин байты перекладывают. Интересно какая библиотека делает memcpy быстрее чем собственно memcpy из libc
Вещь не всем нужная, однозначно.
Вот только один из опенсорсных форков https://github.com/janbar/openssl-cmake
А есть ещё не опенсорсные, в сумме там звёзд немало
Интересно какая библиотека делает memcpy быстрее чем собственно memcpy из libc
Ту, которую писал я :) Но она под NDA) Но большие массивы известного на этапе компиляции размера, и правильно выровненные - копировала на 20% быстрее libc) И да, это тоже была криптобиблиотека.
Вот уж если у чему придираться к openssl, так это к API. Сборка- это реально последнее что там сделано плохо.
К слову, там есть куча ОС-специфичных частей. Например взять хранилище сертификатов. Оно там реализовано совершенно по-разному для Win/Lin/Mac. Абстракция BIO включает в себя обертки над советами и низкоуровневыми функциями работы с файлами. Secure Allocator - в Линукс и Windows реализованы совершенно по-разному и зависит от системных вызовов. Генерация случайных чисел тоже использует системные API для источника энтропии. Опять же, система плагинов (Engines/Providers) привязана к системным dlopen и Load library.
И, кстати, внутри openssl куча кода на ассемблере под 100500 разных архитектур и рантаймов. Мы даже в UEFI окружении смогли её собрать и запустить.
Кароч, там ну очень большой комбайн под капотом
Чтобы понять насколько удобна и хороша библиотека есть очень хороший критерий. Это соотношение форков к звёздам
В хорошей библиотеке форков очень мало, потому что не требуется библиотеку под свои цели модифицировать
А вот в openssl форков аж 11 ТЫСЯЧ и это только официально форки, а не git clone + change
Почти половина от звёзд это форки, это потрясающе плохой показатель. Значит каждый кто захотел использовать библиотеку сделал форк и что то в коде менял, чтобы использовать openssl
Автор не любит "PERL" (видимо считая его страшным демоном прошлого), но любит cmake
И вы любите!!! /s
Не использует openssl для сборки autotools
Нет у openssl обязательных зависимостей. Ну, если не считать Perl, на котором написана сборочная система. Но Perl работает на Винде исправно
Я плюсанул, но все же подушню: система конфигурации openssl не на автотулзах написана, а на перле. Но при этом со своей задачей она справляется неплохо. Поддерживает кучу платформ, о которых ОП, я уверен, даже не слышал.
Openssl не использует autotools. У них своя система сборки, написанная на Perl
а я соглашусь с автором, постоянно, пытаясь использовать сторонние библиотеки в проекте, особенно опенсорсные, сталкиваемся с такой проблемой. Иногда проще свою библиотеку сгенерить, чем использовать что-то с гита... как из другого мира.
Может, и из другого.
Скажем, когда я был в мире FreeBSD - там любая программа из портов собиралась двумя командами:
./configure
make
И если надо было прихолхозить что-то постороннее - в этом постороннем тоже как правило присутствовало либо configure, либо уже сделанный Makefile, т.е. достаточно было make
Мир был прост и понятен. Всё прекрасно собиралось и работало.
В чем проблема? Может быть в том, что юниксовый софт теперь хотят собрать в мире Винды?
почему у юниксоидов и тех кто пишет на С такое большое желание привязаться к одной платформе и желательно к одному дистрибутиву, в идеале - к одному компьютеру, на котором запускается их поделие?
почему у юниксоидов и тех кто пишет на С такое большое желание привязаться к одной >платформе и желательно к одному дистрибутиву
А причем здесь язык и ОС? Логично же, что если ты используешь ОС XYZ, то ты под ней и opensource проекты пишешь и тестируешь. А чтобы протестировать под другие ОС и компиляторы, то это нужно приложить дополнительные усилия, и поэтому естественно, что любые проекты (с открытым или закрытым исходным кодом) в первую очередь заточены под окружение на котором они разрабатывались?
нет не логично. Большинство проектов на С++ уже не привязаны к одной ос, про другие языки даже не говорю. То есть это специфично именно для С
нет не логично. Большинство проектов на С++ уже не привязаны к одной ос, про другие языки даже не говорю
На самом привязаны, даже если у них используется cmake. Вот недавно собирал такой проект. "cmake" единственная система сборки в проекте. Но при сборке под Visual Studio куча ошибок, и один ICE (internal compiler error, то есть падение компилятора). И это не из-за использования какого-нибудь Linux/macOS специфичного API, а просто разное понимание стандарта C++ у clang/gcc и компилятор в составе Visual Studio. И все это потому, что никто никогда не тестировал работу под Windows, авторы проекта не используют эту ОС.
Если никто не тестирует код по несколько платформ, то код магическим образом не станет кроссплафторменным. В большинстве случаев, поддержка той или иной ОС, появляется потому что кто-то пришел, протестировал, поправил проблемы и отправил "pull request", а не наоборот магически код был кроссплатформенным, а потом "злые" юниксоиды его специально поломали.
сборка под разные системы и под разные компиляторы это не одно и то же. Нет никакого смысла в использовании msvc - я специально слежу, чтобы ВСЕ мои проекты давали ICE на msvc. Изначально так получилось само собой, потом просто пошло в традицию. Используйте clang
Как же вас «обожают» все кто использует ваши творения… Особенно когда после компиляции «защитник винды» просто сносит все только что скомпиленное)))
Нет никакого смысла в использовании msvc
Простите, а как скомпилировать CUDA под Windows без MSVC?
Не могу понять логики. А если есть только msvc? Например, по соображениям каких-то корпоративных ограничений работодателя? Ну, тупо куплен только Windows, и пользоваться можно только им, а согласование добавления очередного "самого лучшего" clang'а крайне затруднительно по административным причинам (согласование дольше подготовки релиза)?
Зато всем показал, чем пользуются взрослые дяди, всех воспитал, чтоб неповадно было, и чтоб не работали где попало.
В общем, вредительство, причём сознательное, замешанное на ханжестве.
Вредительство это сам msvc и его поддержка. Чтобы его поддерживать требуется портить код. Он постоянно падает в ICE, не поддерживает правильное поведение и сохраняет баги в поведении, отказываясь его фиксить
Если компания разрешает только msvc - это её проблемы. clang опенсорс в отличие от закрытого msvc, поддерживает С++ лучше, скомпилированный код работает обычно на 30%+ быстрее
Вредительство это сам виндовс и его поддержка. Чтобы его поддерживать требуется портить код. Он постоянно падает в BSOD, не поддерживает правильное поведение и сохраняет баги в поведении, отказываясь его фиксить
Если компания разрешает только виндовс - это её проблемы. Linux опенсорс в отличие от закрытого виндовс, поддерживает С++ лучше, программы работают обычно на 30%+ быстрее
Ну, так пускай работоспособностью занимаются сами виндузятники? При этом только не надо вставлять палки в колёса: от проставления комментариев на строчке кода, что корень проблемы, до принятия патчей.
Случай из реальной жизни.
Есть тип.
Если писать
void foo(myType);
то msvc выдаёт internal compiler error
Если писать
void foo(myType&&);
то компилируется
Вопрос, нужно везде во всём коде писать myType&& и избегать myType по значению из-за того что мсвц падает или всё таки сказать, что он не поддерживается и никогда не будет поддерживаться?
Он постоянно падает в ICE
Ещё бы, Вы же сами сказали, что специально портите свой код, чтобы возникала ICE.
Если компания разрешает только msvc - это её проблемы.
Но создаёте их Вы, и сознательно. Это и есть суть вредительства.
Вы совершенно неверно понимаете суть open source: одно дело – пропагандировать свой подход (использование clang'а), другое дело – сознательно мешать другим использовать иной подход, специально затрудняя компиляцию другими компиляторами. Это уже сознательное вредительство и крайне некрасивый ход, граничащий с преступным поведением.
Но я понимаю, что open source – это ещё и право быть любым чудаком, даже на букву "м". Просто это противоречит духу open source, и он очень страдает от такой "поддержки", но ломать другим веселее, ясное дело.
Ещё бы, Вы же сами сказали, что специально портите свой код, чтобы возникала ICE.
я не порчу код, я просто компилирую мсвц и убеждаюсь что он выдаёт ice
Не знаю почему вам так сложно принять мысль, что я никогда не стану поддерживать "компилятор" у которого не по стандарту работает препроцессор, tuple, no_unique_address, взятие адреса на временные объекты и даже макрос выдающий версию С++, инстанцирование и проверка всех шаблонов, std::exception и тд
Тот, кому понадобится именно msvc, назовет аффтара ***аком и запилит форк с ifdef. Или просто назовет ;).
Вот практическое подтверждение, что msvc находится в 1997 году всё ещё
https://godbolt.org/z/1he3zMhGY
Кстати, объясните почему для любых компиляторов и платформ на godbolt можно запустить программу, а для msvc - нельзя. Ах да...
Надо учить матчасть. в данном случае указать Zc:__cplusplus, будет 202400 aka C++26 по дефолту (в старых версиях С++17)
Майков справедливо ругали за плохую поддержку стандарта (и за кодогенерацию), но в последнее время они подтянулись
А Вас никто не заставляет ничего поддерживать. Нужно просто специально не следить.
Вижу, что Вы так и не поняли разницы.
Вижу вы так и не поняли что вам хотел сказать @Kelbon
ну к примеру опенссл с опенбсд и с линукса разные на сколько помню
Есть FreeBSD, OpenBSD, Linux, DragonFly, платформы x86 и arm, 32 и 64-битные.
Везде программы на C успешно компилируются, работают.
Но это всё "одна платформа и один дистрибутив", потому что не Винда )
А вот с Виндой было бы сразу много платформ...
Ах да, еще make install
Где-то начиная с версии 2.2.5 - вот этими командами.
А у ВАС как собирались программы из портов? Поведайте.
я ффмпег собирал из портов, собралось на тот момент со всеми зависимостями
вообще-то там не просто мейк, а автоматизированный с велосипедами
тоесть мейк там функционал носит, это не совсем таже ситуация как в линуксе например мейк, там система портов ближе к ебилдам на генте, но вообщем поудобнее, фряха вообще если быть честным по-удобнее
хотим мейкаем, хотим pkg build - make делаем, ядро встроеное, система ярко выраженная, настройка минимальная, вот стим-устройство не просто арч-линукс выбрали, такой подход вообще имба, но линукс не фрибсд конечно
вообще сейчас у фрибсд всё ярче ярче будут преимущества я считаю, они просто доведут до единого какого-то 1-2(терминал и гуй, да и самому можно скрипт написать, система вся на файликах и скриптов не много на настройке для воркстейшн) решений и всё - чай обновились с 80 годов
--
фряха бьёт по рукам либо если pkg-build-make игнорировать, либо если обновлять не правильно и не делать бекапы, если всё скурпулёзно делать, то изи
например в генте на тоже самое чисто больше движений
Ну как сказать, то, не то:
./configure анализирует наличие нужного
make просто собирает по сформированному Makefile.
Кстати сказать, и сейчас иногда в линуксе - имеет смысл заглянуть во фришные порты, скачать исходники и собрать по той же схеме. Но теперь уже с нюансами, плюс могут потом возникнуть проблемы, если пакеты обновились, и зависимости изменились.
меня на днях угораздило собирать ffmpeg под windows - чуть не помер
документация - это разрозненные статьи (в т.ч. и официальная) разной степени устаревшести. в итоге получилась своя собственная инструкция на несколько экранов
Вы хотите, чтобы "юниксовый софт" был только там и только там?
Как бы это сказать...
Допустим, я люблю жареную картошку, шашлык и пироги с вишней: и я представляю себе как их готовить, соответственно на печке, на костре, в духовке.
А кто-то хочет готовить жареную картошку, шашлык и пироги в кофеварке. Ну кофеварка красивая потому что, и нравится.
Так вот, почему я хочу жарить картошку исключительно на плите, и почему не хочу жарить ее в кофеварке?
Ровно по той же причине, по которой в кофеварке я не буду жарить шашлык.
Потому что кофеварка для этого неудобна! А не потому, что мне картошки для кого-то жалко...
vcpkg install openssl opus
Это ещё один повод спросить, почему в процессе разработки рецептов для этих библиотек (они чудовищно сложны) не был создан CMakeLists.txt. Может быть microsoft выгодно, чтобы подключить эти библиотеки было подъёмно только через vcpkg?
И да, не знаю ни одной компании кроме microsoft, которая бы использовала vcpkg для разработки
Это ещё один повод спросить, почему в процессе разработки рецептов для этих библиотек (они чудовищно сложны) не был создан CMakeLists.txt
Потому что никому (кроме особо упоротых) не хочется поддерживать свою сисетму сборки по множеству причин, начиная от обязанности отслеживать абсолютно все изменения в оригинальной системе сборки и заканчивая всякими аудитами безопасности.
Что? Так ведь это и сделал microsoft, сделал кучу патчей к опенссл, свой рецепт, вместо того чтобы написать cmakeLists и пихнуть его в openssl?
Патч != система сборки. Рецепт != система сборки. Даже при наличии CMakeLists.txt нужен рецепт.
Патчи существуют в т.ч. для того, чтобы подогнать установку под свои представления о прекрасном (installation layout, протягивание флаги компиляции и т.п.)
Ну и роль MS во всём этом скорее проревьювить изменения и нажать кнопку merge, сами правки вносят обычные люди и те самые компании, о которых вы не знаете.
Так vcpkg это аналог pkgbuild из арча, deb скриптов и подобного. Т.е. тут обертка вокруг ./configure && make install а не переписываниею autotools, perl и прочего на симейк.
Обертку сделать в разы проще чем портировать миллион скриптов на симейк. И вообще если там требуется действительно что то сложное заскриптовать, то симейк как язык по сравнению с перлом это убожество.
Потому что опенссл старше цмейка?
Вообще не нравится цмейк - кривое кривое. Было, потом долго пилили, результат уже не смотрел.
Естественно инженер АСУТП не хочет ни в чём разбираться, и продолжает рассказывать про "замечательные" сишные способы собирать сишный мусор
опенссл старше QUIC, но почему-то он там поддержан (костыльно при том)
Смейк плох, но он используется большинством современных библиотек и поддерживается всеми популярными IDE. В том числе потому что в нём есть всякие фичи типа экспорта compile commands в JSON (и его архитектура позволила это сделать).
Остальные системы сборки используются в 3.5 проектах и почти не поддерживаются в IDE, либо фундаментально не позволяют нормальную поддержку инструментами (например, потому что система сборки это тупо самописный скрипт и compile commands генерировать получиться только руками).
Так что CMake необходимое зло.
Ну я помню пару мелких, например vcpkg использует Telegram в своей tdlib, в Windscribе собирается клиент для Win.. ну это только что я сам собирал и помню, а у старых проектов как правило свои системы сборки, обросшие скриптами по самые дебри, с которых никто переходить не спешит, даже на CMake, у которого в последнее время от версии к версии тоже что-то периодически ломается, и приходиться даже понижать версию что бы собралось
Потому что эти библиотеки начали разрабатывать до того, как появился в принципе СМаке.
Да, это так. Я, например, такой старый, что помню, что когда-то CMake не было.
А когда он появился, то далеко не сразу стал достаточно распространённым, чтобы серьёзную библиотеку перенесли на него. Системы сборки, извините, каждый год новые появляются.
глянул на порт openssl для vcpkg, это только одна из многих папок с патчами, которые приходится при сборке применять, чтобы оно собралось(представляю объём работ по поддержке этого рецепта):
Можете не представлять, а увидеть воочию: https://github.com/microsoft/vcpkg/commits/master/ports/openssl
Согласен, поменять номер версии и хэш архива с исходниками - это очень сложно.
Так там по ссылке 4-5 страниц коммитов по порту Openssl, как будто для нормальной библиотеки хватит ровно одного коммита с рецептом, вам так не кажется?
Эмм... А обновляться оно само будет?
Будут обновлять те кто делает openssl. Правда тогда vcpkg не нужен будет никому, просто напрямую подключить смогут
Задача OpenSSL - опубликовать релиз и иметь инструкцию по сборке, с ней они справились. Как подключить в ваш проект - это ваша головная боль, OpenSSL не должен пытаться усидеть на как минимум четырёх стульях: CMake, meson, bazel и autotools.
Можно поддерживать самое популярное, что уже много лет CMake.
самое ли это популярное среди спонсоров опенссл?
./configure + make install популярнее. Значительно популярнее.
cmake используется в 83% проектов и это число растёт, уже почти 2026 год, статистика за 2024
https://moderncppdevops.com/2024-survey-results/
"папок". ясно. понятно.
Вижу, что автор Kelbon - бегу читать
Поднята интересная тема, правда вряд-ли здесь есть какой-то массонский заговор больших корпораций, скорее всего здесь педантизм и упертость основных мейнтейнеров, встретился с проблемой из статьи когда надо было на основе всех библиотек с cppreference готовить какой то парсинг для дальнейшего обучения на их документации ИИ, и вот для C библиотек парсинг попросту нельзя было настроить так как чтобы добраться до реального расположения документации приходилось проходить несколько кругов ада, так как некоторые ссылки это просто приветственные слова автора :) Отдельное спасибо всем тем авторам которые пишут C++ обертки для таких библиотек с хорошей документацией и удобной сборкой
Соглашусь с автором по многим вопросам, так как сам "ковырялся" в исходниках openSSL - это просто ужас. Но это общая проблема, чем больше разбираешься в open-source продуктах, тем меньше желание их использовать.
Берешь любой исходник и ты можешь найти, что половина кода - это статические функции типа: функцию return (например, return a==b), функция из одной строки, функции-переходники (функции, которые вызывают другую функцию с какими-нибудь фиксированными значениями) и функции типа "швецарский нож".
Я тоже когда-то задавался этим вопросам, зачем все эти сложности.
Оказывается, за рубежом так учат в универах! Функция не должна быть громоздкой в написании. Мол, функцию написаную в 5-10 строчек кода, легче понять и разобраться в ней и без комментарий. Отсюда и стиль написания кода: сложные функции разбивают на подфункции, в свою очередь и подфункции разбиваются на более простые. Отсюда и получаем, что любой С-файл - это 4/5 статических функций и 1/5 кода - это функций, которая вызывают эти функции. В реале получается все наоборот, очень трудно разобраться в этой "солянке".
К примеру, при вызове какой-нибудь функции GNOME создать очередь из 20 функции в стеке вызовов - это воплне рядовое явление.
Добавлю: у меня тоже возникло ощущение, что open-source решение, специально усложняют, чтобы исходник кода было сложно администрировать. Нам же рассказывают сказку, что код доступен, любой может скачать и разобраться - нифига, это не работает!
Вы просто мало close source видели :). Ну т.е. после какого-нибудь местечкового легаси все "проблемы" open source кажутся совершенно надуманными.
Мол, функцию написаную в 5-10 строчек кода, легче понять и разобраться в ней и без комментарий. Отсюда и стиль написания кода: сложные функции разбивают на подфункции, в свою очередь и подфункции разбиваются на более простые.
Потому что это правда.
Короткая функция, которая делает четко определенные действия, + к ней тест, который может проверить эту функцию (к сожалению на тесты часто забивают).
Нужно сложное - будет вам 20 простых функций, каждая из которых заведомо работает, а значит и результат сложной функции зависит только от ручек ее автора.
Другой подход - налепить в одну функцию 100500 строк всякого, где 156-я ссылается на переменную из 84, которая меняет значения в сотне строк только этой функции (не говоря о любителях глобальных переменных) - это называется спагетти.
А потом они удивляются неожиданному поведению функции, утечкам памяти и выходам за пределы массивов...
Берешь любой исходник и ты можешь найти, что половина кода - это статические функции
Теперь берём исходник закрытой коммерческой программы. Открываем файл и видим ссылку на библиотечную функцию. Что же в функции? Этого мы никогда не узнаем, потому что библиотека поставляется бинарником и за отдельную плату. Производитель библиотеки запрещает знать, как устроена эта функция и что она делает с глобальными переменными.
зачем все эти сложности
Чтобы никто не смог узнать, что там в библиотечных функциях, и не смог их украсть.
Мне кажется, вывод неверен из-за использования небольшой выборки в которую включили довольно специфичные проекты.
Что openssl, что кодеки для популярных форматов, это с одной стороны код, которым пользуются миллионы пользователей, а другой стороны напрямую этими библиотеками пользуются довольно мало программистов, так как большинство используют какие-то обертки над ними, типа Qt/network, Python/urllib и тому подобные.
Поэтому и удобство непосредственно использования для них вторично - все основные пользователи уже написали обертки, а вот функционал/безопасность/баги для них важны, так как через те же браузеры их код используют миллионы, и соотвественно что нужно починить/поправить в проекте у них всегда найдется.
Не жалуйтесь на жизнь а предложите как это поправить ...
Так исторически сложилось. Почти всегда использование с библиотек связано со сложностями. Но тут ничего не сделаешь, глотаем слезы и пытаемся это внедрить в свой код. Не будешь же ты на серьёзных щах писать свою реализацию допустим datamatrix(упахаешься). Проще взять готовую библиотеку написанную 20 лет, назад 100% рабочую, испытанную десятилетиями и ее использовать.
Для незнакомых с ситуацией вкратце - любая библиотека на С это в конечном счёте всего лишь набор .c файлов и набор .h файлов, а также опции компиляции
Бинго! Вот это самое верное. Не забываем насколько Си язык простой. Это не Си++. Любой проект на Си можно "раскрутить" относительно быстро, если вы умеете пользоваться поиском по файлам в папках. Возьмите тот же notepad++. В хорошей библиотеке все имена идентификаторов написаны с умом, клубок быстро распутается, можно будет забрать только те файлы, которые необходимы вам. Кстати так и интегрируют старые проекты в свои: добавляют CMakeLists.txt в папке уровнем выше над субмодулем.
А мусорных файлов там нет. Каждый был сделан для чего-то, для какой-то платформы, может быть для какой-то совместимости с чем-то, что работает 20-30 лет стабильно и без перебоев.
Есть сложившая практика и она хорошо работает. Лучшее - враг хорошего. Так что потратить время немного придется, можно принять это как факт при разработке на Си.
Ну да. Есть неприятные случаи, когда нужно перед сборкой генерировать что-то инструментами типа bison и flex.
Вот Вы говорите, напишите свой. Я и написал. Для одного проекта, который саппортит один разраб, который чтобы скомпилировать, надо так напрячься, что потом уже не захочется. Я просидел недели две, собирая красивый cmake-файл, чтобы всё аккуратно собиралось, без мозгоедства, и предложил PR. Так автор отклонил его по причине... он не будет его саппортить. Ему удобнее через анус. Проект Blastem - эмулятор Sega Mega Drive.
Сделайте форк. Люди так делают иногда.
а с чего вы взяли что можете прийти к человеку и сказать - эй, вот те работенка, надо сделать, мне так удобно.
Для него ваш cmake такой же анус как для вас его configure && make)
Для одного проекта, который саппортит один разраб, который чтобы скомпилировать, надо так напрячься, что потом уже не захочется.
кстати, как вы там это собирали? Я за 5 минут управился - запустил make -j. Всего одна проблема вылезла - -Wincompatible-pointer-types. Спасибо за ссылочку, интересно изучить.
Вы ещё не видели проекты для работы с TPM: это худший API и худший реп, который я видел - TPM2-TSS. Открываешь почитать апишку, надеешься понять, что она делает, а там лишь общие слова, типа: это апи, и оно открывает хэндл (условно, название апи OpenHandle). А найти тело функции вообще нереально, так как оно проходит через тонну врапперов и в итоге приходит в код, которого даже нет в текущем репе.
Первая проблема C, которая так же преследовала плюсы, - отсутствие стандартов. С момента появления и до настоящего времени подход к разработке либ был самым разным, каждый делал как чувствует и в итоге всё невероятно разное.
Ну а проблема опенсорса - это вечная проблема. Один делает так, другой наперекосяк, а третий вообще не в курсе, что первые два делали и делает то же самое, но другим способом. Опенсорс это благо и величайшее зло.
Поэтому многие компании просто берут... и пишут свои либы. Такова реальность по крайней мере сишки и плюсов. Поэтому если либа открытая, то лучше просто из неё вычленить что надо и работать с этим как со своим кодом
Поэтому если либа открытая, то лучше просто из неё вычленить что надо и работать с этим как со своим кодом
Игнорировать атрибуции - не по-джентльменски.
Первая проблема C, которая так же преследовала плюсы, - отсутствие стандартов.
Мне чем нравится Java - там с этим более-менее порядок, нет фрагментации в решении определенных классов задач в разработке. Например - код и тесты разделены и размещаются по стандартным путям, системы сборки (в прошлом Ant, сейчас Maven и Gradle), одна IDE. Очень удобно, снижает когнитивную нагрузку.
В какой-то момент нужно всё таки вспомнить, что это всего лишь набор .c файлов, которые должны зашифровать байты и расшифровать байты. Откуда здесь взялась эта сложность?
Ну нет, не соглашусь. Там чего только нет. И быстрая арифметика больших чисел, необходимая для RSA, и куча криптоалгоритмов, ассемблерные оптимизации под множество платформ, плагины какие-то, поддержка аппаратных ускорителей. Возможность комбинировать алгоритмы в рамках более масштабной функциональности (например, возможность выбрать хеш-функцию или блочный шифр или режим использования блочного шифра, независимо друг от друга). Даже своя реализация ASN.1 на сишных макросах :-)
Так что нет, это не просто "зашифровать байты и расшифровать байты".
Что она внутри там не красавица, да, с этим сложно спорить.
При этом нет самого важного - описания что это за библиотека, из чего состоит, как её использовать, документации.
Я в этих ваших openssl не разбираюсь, cmake на помойке нашел, но зачем в том репе на картинке бесполезная папка doc?
Виноват именно что язык Си. Он не предоставляет необходимой гибкости и абстрактности. Из-за этого многие велосипедят свои скрипты кодогенерации и препроцессоры, что усложняет сборку проекта. Веселья добавляет необходимость сборки какими-нибудь экзотическими компиляторами, которая нужна некоторым пользователям данных библиотек.
По-хорошему тот же OpenSSL должен быть переписан на C++, при чём по-нормальному, а не как это обычно сишники делают. Тогда бы код стал бы сильно проще и для сборки хватило бы тривиального Cmake файла.
Хороший пример библиотеки на C++. Собирается с пол-пинка, имеет чёткий и лаконичный API.
Да, как по мне cargo - это лучшее что случалось в системах сборки и управления зависимостями. Раньше любил модули Go, но cargo ещё лучше.
Не идеально, да, но близко к тому.
Не только система сборки, хотя она хороша, да.
Общая культура другая.
Си: документация = код, читайте код. Если разберётесь.
Rust: дока на публичные апи, часто с кейсами.
А карго умеет так, в многоступенчатую сборку ? :
Выполнить предварительный шаг сборки, подготовки под платформу
Запустить генератор кода типа bison/yacc. Перемесить ими половину исходников
Запустить наконец компиляцию
И вообще, работать с чем то кроме Раста?
А карго умеет так
Там можно всё что угодно сделать, в принципе, через build.rs- часто так и делается, если по-другому никак.
И вообще, работать с чем то кроме Раста?
Такой цели и не ставилось. Универсальный инструмент будет, по определению, хуже и сложнее.
через
build.rs
Ну да, конечно это лучше скриптов на Perl, понятненько =)
Не очень понятно что вы хотите от старых проектов на языке из прошлого века с соответствующими подходами. Сегодня есть LLM, которые как-то справляются с документированием и пониманием такого легаси.
Есть deepwiki у которой неплохо получается все это описывать https://deepwiki.com/openssl/openssl
Для Си и С++ нет пакетного менеджера, все делают как хотят. И делают так почти 50 лет.
Те, кто не хочет возиться со сборкой этого легаси, давно юзают Nix, где в nixpkgs есть подавляющее большинство сишных проектов и собираются они одной кнопкой.
А вообще в целом странно ездить на запорожце и требовать наличия кондиционера. Осваивайте новые технологии.
Вы пишите
С документацией вообще обычно всё плохо, во многих библиотеках вам предлагают... Скачать репозиторий, собрать его, а потом запустить некий скрипт, который соберёт вам документацию.
А до этого приведена картинка из openssl репозитория и складывается впечатление, что документацию по openssl надо рендерить самому. Но там в readme после раздела build & install идёт раздел documentation со ссылками на docs.openssl.org, где вся документация в удобном виде и даже гайд, объясняющий как написать сервер или клиент под разные протоколы.
любая библиотека на С это в конечном счёте всего лишь набор .c файлов и набор .h файлов
Это начало, а не конец. Конец - это набор .a, .so и .h.
Десятки гит сабмодулей, бесполезных папок, PERL, сотни и тысячи бесполезных файлов. При этом нет самого важного - описания что это за библиотека, из чего состоит, как её использовать, документации.
Описание библиотеки (или вообще любого проекта) ВСЕГДА написано в README.
Документация может быть: там же в README (или там может быть прописано, где она), в отдельном файле DOCS, в отдельной папке doc/docs, в виде Wiki (на том же GitHub) или вообще в виде MANа.
А остальные файлы тебе и не нужны.
авторы вынуждают прочитать весь этот мусор
Нет.
Раздел "как собрать" обычно состоит из громадного списка if, интерпретировать построчно должны ВЫ, например:
Что тут "интерпретировать"?
Заметки вынесли в отдельные файлы для каждой платформы, чтобы не делать README слишком большим. Так открой файл NOTES-ТВОЯ_ПЛАТФОРМА и всё (или нажми на нужную ссылку, если ты обычный чел).
Но по видимому ни одна компания так и не решила запросить у openssl ну не знаю там, CMAKELISTS.TXT НАПРИМЕР???
Там есть свой скриптик на Perl (Configure), а опции для этого скриптика прописаны в нём же на 50 строке. Тот же самый CMake (если я правильно понял, как он работает, сам никогда не использовал).
Никакого описания как устроен репозиторий
А что тут писать? "Ну, это git-репозиторий, сорцы в src...". Или я не правильно понял?
никакой документации
Папку doc смотрел?
скрипт который должны исполнить вы
А что не так? Типа за тебя это должен автоматом делать робот, когда уловит мысль "хочу собрать"?
UPD: А вообще, зачем тебе самому собирать? Ну вот прям ручками. Даже гентушники собирают автоматом, другие просто из репозитория устанавливают.
Documentation - ссылка на ЭТУ ЖЕ страницу
Нет, не на эту же, если я вообще понимаю о чём ты.
В целом, с автором не согласен, по крайней мере с примерами, которые он привёл.
Собираются только под одну платформу, собираются с трудом, закрытые сообщества - чтобы отправить баг нужно ЛИЧНОЕ знакомство с кем-то из "тусовки",
Бред какой-то. Не знаю никого ни из какой "тусовки", что никак не мешает репортить баги и отправлять патчи в Linux.
весь open source такой
почему? ну, например, потому, что никто не любит заниматься супер скучным делом -- писать документацию
По итогу ответа у нас нет - есть лишь гипотезы. Имхо - все дело в заинтересованностях, в частности есть большие силы и капиталы, которые хотят иметь бекдоры. А в мутной водице, как говорят, черти водятся...
Нет, я не про сложность задач, которые они решают
А вы осознаёте сложность задач, которые решают приведенные в качестве примера библиотеки? Ну, ради интереса освойте хотя бы один RFC для TLS 1.3, в котором 160 страниц) А потом вспомните, что были ещё TLS 1.2, в котором примерно 6 основных RFC и ещё десятка полтора расширений) А также ещё все предыдущие версии TLS и SSL, и все это ещё и совместимо между мажорными релизами библиотеки)
И да, где-то в комплекте, ещё поставляете утилиту по тестированию работоспособности этого дела) На любых ОС и аппаратных платформах)
Можете прочитать также FIPS 140-2 (ну или более современный FIPS 140-3), чтобы прикинуть масштаб проблем, которые приходится учитывать) Докиньте до кучи то, что 100500 языков с вами хотят интегрироваться, и то что библиотека старше вас, и получите точно такой же "бардак", который существует в OpenSSL.
Это далеко не идеальная библиотека. Там половина API - это просто дикий ужас, а код внутри местами... Ну, месяца на 2 можно в одном файле застрять) Тем не менее, оно работает и собирается с полпинка вообще везде)
Как-то очень смело наброшено именно на Си. Не преуменьшая всех озвученных проблем, хочется спросить, а что, разве с другими языками прям всё хорошо? Вот прям и код чист, и абстракции понятные, и без ошибок? Один жаваскрипт чего стоит. Вот уж где библиотек понаписано - никаких гигабайт не хватает уже.
Выглядит как общая проблема. Каждый может класть кирпичи, но далеко не каждому дано выстроить Дом. Кухарка и государство.
Используйте лучше BearSSL
Очень компактная либа
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Почему библиотеки на С такие кривые