LINUX.ORG.RU

plibsys — кросс-платформенная системная библиотека на C

 , , ,


10

7

Недавно ко мне обратились с вопросом, не хочу ли я написать новость об одной из разрабатываемых библиотек (plibsys). В принципе, я не против, поэтому эксклюзивно для LOR.

Что такое plibsys?

plibsys — это кросс-платформенная системная библиотека, написанная на чистом C. Основной упор был изначально сделан на портируемость и поддержку широкого спектра компиляторов. Для достижения этих целей у библиотеки отсутствуют (небольшим исключением является SCO OpenServer 5 ввиду отсутствия на ней потоков) какие-либо зависимости — используются только те вызовы, которые доступны в целевой ОС. Также никакого ассемблера и использования прочих недокументированных возможностей. Для сборки нужен только рабочий компилятор и CMake.

Изначально библиотека писалась для запуска потоков и работы с сокетами, но постепенно функционал расширялся по мере необходимости. На данный момент есть следующий функционал:

  • Платформо-независимые типы данных
  • Потоки и средства синхронизации: мьютексы, условные переменные, блокировки чтения-записи, спинлоки, атомарные операции
  • Межпроцессное взаимодействие: семафоры, разделяемая память, кольцевой буфер
  • Сокеты (UDP, TCP) с поддержкой IPv4 и IPv6
  • Хэш-функции: MD5, SHA-1, SHA-2, SHA-3, GOST (R 34.11-94)
  • Бинарные деревья: несбалансированное, красно-черное, АВЛ
  • Загрузка разделяемых библиотек
  • Работа с памятью: mmap, установка собственного аллокатора
  • Замер времени исполнения (по возможности — в высоком разрешении)
  • Базовая работа с файлами и директориями
  • Парсер файлов INI
  • Макросы для определения архитектуры ЦПУ, ОС и компилятора
  • Различные вспомогательные структуры данных типа связанного списка, хэш-таблицы, обработка строк

На все есть документация.

Поддерживаемые платформы и компиляторы

Абсолютно все модули покрыты Unit-тестами. Есть интеграция с CI (Travis, AppVeyor), где прогоняется большое число разнообразных конфигураций. Также для улучшения качества кода и снижения числа ошибок используется сервис статического анализа кода Coverity. Для оценки покрытия тестами используется Codecov.

На данный момент поддерживаются следующие платформы:

  • GNU/Linux
  • macOS
  • Windows, Cygwin, MSYS
  • FreeBSD, NetBSD, OpenBSD, DragonFlyBSD
  • Solaris
  • AIX
  • HP-UX
  • Tru64
  • OpenVMS
  • OS/2
  • IRIX
  • QNX Neutrino, BlackBerry 10
  • UnixWare 7
  • SCO OpenServer 5
  • Haiku
  • Syllable
  • BeOS

Также работоспособность библиотеки проверена на следующих компиляторах и архитектурах:

  • MSVC (x86, x64) 2003 и выше
  • MinGW (x86, x64)
  • Open Watcom (x86)
  • Borland (x86)
  • GCC (x86, x64, PPC32be, PPC64be/le, IA-64/32, IA-64, Alpha, HPPA2.0-32, MIPS32, AArch32, SPARCv9)
  • Clang (x86, x64, PPC32be)
  • Intel (x86, x64)
  • QCC (x86, AArch32)
  • Oracle Solaris Studio (x86, x64, SPARCv9)
  • MIPSpro (MIPS32)
  • XL C (PPC64le)
  • DEC C (Alpha)
  • PGI (x86, x64)
  • Cray (x64)

Особенности работы библиотеки, сборки и тестирования на разных платформах с разными компиляторами подробно рассмотрены в Wiki.

Что дальше?

Библиотека по-тихоньку продолжает развиваться, хотя, к сожалению, свободного времени не так много. Например, недавно была добавлена поддержка для систем Cray.

Планирую сделать родной пакет для Debian. В общем-то, он готов, надо только протестировать. В связи с этим, если кто-то сможет выступить в качестве поручителя (он же sponsor в терминологии Debian) для проверки и заливки пакета — буду рад.

Если у кого-то есть доступ к каким-то машинам и компиляторам, которых нету в списке, и есть возможность организовать удаленный доступ для портирования — буду рад. В данный момент было бы интересно проверить под HP-UX с компилятором HP C/aC++. Или на машинах уровня BlueGene с компилятором IBM XL. Или на AmigaOS.

Пожелания, комментарии (конструктивные и не очень) и поток сознания (в меру) по библиотеке приветствуются :)

>>> Подробности

Хэш-функции: MD5, SHA-1, SHA-2, SHA-3, GOST (R 34.11-94)

Парсер файлов INI

Работа с памятью: mmap, установка собственного аллокатора

И вот чего эта либа пытается добиться - поди разбери. Какая-то каша из всего подряд.

Bfgeshka ★★★★★ ()

Спасибо, я вздумал написать свою «Mini OS» с использованием вашей билиотеки.

RedEyedMan4 ★★★★★ ()

Не знал, что в мире есть столько разных ОС и компиляторов Ц

anonymous ()

не использовал, но выглядит годно. На всякий случай сделал пакет для арча https://aur.archlinux.org/packages/plibsys/

PS при сборке с новеньким gcc выдал ворнинг

/home/arcanis/plibsys/src/plibsys-0.0.3/src/pdir-posix.c: В функции «p_dir_get_next_entry»:
/home/arcanis/plibsys/src/plibsys-0.0.3/src/pdir-posix.c:267:2: предупреждение: «readdir_r» is deprecated [-Wdeprecated-declarations]
  if (P_UNLIKELY (readdir_r (dir->dir, &dirent_st, &dir->dir_result) != 0)) {
  ^~
In file included from /home/arcanis/plibsys/src/plibsys-0.0.3/src/pdir-posix.c:27:0:
/usr/include/dirent.h:183:12: замечание: объявлено здесь
 extern int readdir_r (DIR *__restrict __dirp,
arcanis ★★★ ()

SCO OpenServer 5

Вот не понимаю я людей, которые пишут что-то для никому не интересной платформы (для зарабатывания бабла она бесполезна, для энтузиастов в качестве хобби тоже), а потом еще и гордятся этим. И не важно, что любая новая функциональность будет требовать дополнительных усилий из-за необходимости поддержки никому не нужной платформы (где тоже нужно обеспечить новую фичу), зато библиотека максимально кроссплатформенна! Кому вообще может быть нужна совместимость на уровне исходников для суперкомпьютера, десктопа и 8-ми битного контроллера? Ну, кроме менеджера-балабола, который никогда не писал кода и понятия не имеет, сколько ресурсов потребует поддержка такой кроссплатформенности или фанатика-технаря, который пилит это в свое удовольствие, не задумываясь о практичности такого подхода (соотношения затрат и полученной выгоды). Круто, конечно, что кто-то осилил прочитать документацию на кучу платформ и боролся с особенностями многих компиляторов, написал код, протестировал, отладил, но абсолютно бесполезно, потому что никому, кроме создателей, не нужно.

IMHO, новость из разряда «на brainfuck написали крестики-нолики» (даже тетрис на шаблонах C++, который после каждого хода нужно заново пересобирать, более полезен).

Резюмирую: psyslib не нужен.

anonymous ()

Для Ъ:

plibsys is distributed under the terms of GNU LGPLv2 or higher license.

greenman ★★★★★ ()

которых нету в списке

Там точно без багов?

NoviceNIX ()
Ответ на: комментарий от makoven

Наверное конкурент glib

Больше похоже на самый бесполезный и самый кроссплатформенный велосипед.

anonymous ()

Я так понимаю, у автора есть целый зоопарк машин со всеми этими системами, и каждый релиз он прогоняет на нём тесты? Или поддержка запиливалась в режиме «один раз написали и больше не трогаем»?

Судя по количеству звёздочек, у либы есть пользователи. Может автор расскажет, в каких проектах пользуются его детищем? Будь оно под пермиссивной лицензией, я бы ещё понял.

env ★★☆ ()

Честно говоря, на месте автора я бы разделил всю эту конструкцию на меньшие библиотеки (plib-socket, plib-ini, plib-hash и так далее). Ну и зарелизил бы под MIT/BSD, чтобы можно было подключить в свой проект только нужные части, а не тащить всё разом. В текущем же виде я просто не представляю, где это может быть использовано.

env ★★☆ ()

написанная на чистом C

это именно С без стандартной библиотеки, или всё же с её использованием?

почему возник вопрос - интересно, будет ли оно собираться и работать с musl и прочими библиотеками.

Iron_Bug ★★★★ ()

Вах! Крутая штука, однозначно в закладки.

istepan ()

Вот примерно это меня в си и бесит. Вместо пары десятков библиотек ОДИН ЖЫРНЫЙ КУСОК КОДА.

kirk_johnson ★★ ()
#if defined (P_OS_WIN) && (defined (P_CC_MSVC) || defined (P_CC_BORLAND))
  typedef signed __int64	pint64;
  typedef unsigned __int64	puint64;
#else
#  if PLIBSYS_SIZEOF_LONG == 8
     typedef signed long	pint64;
     typedef unsigned long	puint64;
#  else
     typedef signed long long	pint64;
     typedef unsigned long long	puint64;
#  endif
#endif

Не увидел в cmakelist упоминания какой стандарт C вы применяете. Просто данная запись не взлетит на с89/90, ибо там нет long long, а sizeof(long)==8 только на х64.

PPP328 ★★ ()
Ответ на: комментарий от kirk_johnson

Форкни и раздели. Просто если разделишь, то тебе для например парсера ini придется тянуть еще два десятка минибиблиотек по зависимостям (типы, работа со строками, работа с файлами и пр.)

PPP328 ★★ ()

Бенчмарки есть?

Deleted ()
Ответ на: комментарий от kirk_johnson

Обычно наоборот.

Ну и вообще, причём тут язык, если везде можно делать так.

Bfgeshka ★★★★★ ()
Ответ на: комментарий от Iron_Bug

это именно С без стандартной библиотеки, или всё же с её использованием?

Видно, что попытки меньше использовать что-то извне есть, но вообще нет - тут и там можно увидеть всякие инклюды stdlib.h и unistd.h.

Bfgeshka ★★★★★ ()

Это замена libc или что?

mittorn ★★★★★ ()

Некий уменьшенный аналог boost для C.

rumgot ★★★★ ()
Ответ на: комментарий от rumgot

Бывает, что именно такое и нужно. Особенно (я подчёркиваю это!), если приходится иметь дело с разными (разными!) старыми дистрибутивами GNU/Linux.

krotozer ()

Бесполезная работа. Сейчас практически уже везде более высокоуровневые языки, а если уж на С надо - и этого навалом. Не понятен смысл работы

Apache2017 ()

А как собирать под платформы, на которых нет CMake? Или только кросскомпиляция?

buddhist ★★★★★ ()
Ответ на: комментарий от Apache2017

Сейчас практически уже везде

Это всё, что нужно знать про комментирующего в твоём лице.

Впрочем, можно добавить твой недавний топик-просьбу, для более точной характеристики:

«Посоветуйте книги и ресурсы для изучения Python, чтоб быстро въехать в этот прекрасный язык.»

Bruce_Lee ★★ ()

В таких новостях нужно хоть краткое сравнение с glib, apr и подобными. А то выглядит как хобби-велосипед, хотя и с серьезным (не слишком ли?) подходом.

anonymous ()

Чем не подошел APR?

anonymous ()

на ардуине скомпиляеца?

bender ★★★★★ ()

Платформо-независимые типы данных

Кому-то к 2017 году не завезли stdint.h?

Бинарные деревья: несбалансированное

Но зачем?

Ну и непонятно, зачем столько разной функциональности в одной libblackjackandhookers.

Softwayer ★★ ()
Ответ на: комментарий от Softwayer

Кому-то к 2017 году не завезли stdint.h?

Возможно имеется в виду использование платформо-независимых типов в API, например, вместо int функция возвращает аналог int32_t.

anonymous ()
Ответ на: комментарий от anonymous

Хотя нет, беглый взгляд на доку говорит обратное. И сама библиотека довольно скудновата.

anonymous ()
Ответ на: комментарий от kirk_johnson

Вот примерно это меня в си и бесит.
Вместо пары десятков библиотек ОДИН ЖЫРНЫЙ КУСОК КОДА.

При чем тут Си?

andreyu ★★★★★ ()

C диким скрипом либу собрал, пошаманив в правилах сборки, но на ещё большие подвиги для сборки unit-тестов я не готов...

Вот никак не пойму, люди: какого хрена вы все тащитесь с этого гнусно-помойного дерьмостраховища под названием «CMake»???

krotozer ()
Ответ на: комментарий от Bruce_Lee

Причем тут знания Питона и эта библиотека? Или ты всегда делаешь выводы на основании совершенно сторонних суждений?

anonymous ()

проект интересный. лицензия, правда, ограничивает область применения.

насколько я понимаю, мобильные платформы (пока?) не поддерживаются?

что происходит с именами файлов на windows? судя по pchar и отсутствию каких либо трансформаций, не-ascii имена файлов на windows работать не будут?

или абстракции для файлов вообще нет? я нашел только p_file_is_exists и p_file_remove, ну и еще pdir-win.c, дергающий ANSI версии API.

waker ★★★★★ ()

Сборка на «Эльбрусе» потерпела крах.

krotozer ()

И недавно даже первый пользователь здесь на лоре появился: MuZHiK-2, благодаря которому я узнал о либе.

gag ★★★★★ ()
Последнее исправление: gag (всего исправлений: 1)

сначала подумал, что очередная реализация libc

а на Windows XP, 98 работает?

Harald ★★★★★ ()
Ответ на: комментарий от lberserq

ну то, что оно под 2003 студией конпиляется, еще не значит, что будет со всеми заявленными фичами под XP и тем более 98 работать

Harald ★★★★★ ()
Ответ на: комментарий от waker

судя по pchar и отсутствию каких либо трансформаций, не-ascii имена файлов на windows работать не будут?

Имя файлов это просто набор байт, какая разница в какой оно кодировке. Как оно в аргументах пришло, такое и используешь.

Это самое тупое, что было сделано в py3 — пытаться угадывать кодировку имен файлов и делать вид что там юникод.

anonymous ()
Ответ на: комментарий от anonymous

Имя файлов это просто набор байт, какая разница в какой оно кодировке. Как оно в аргументах пришло, такое и используешь.

все несколько сложнее. типично имена файлов и весь интерфейс в UTF-8. если у тебя кроссплатформа, то скорее всего форматы файлов тоже UTF-8, и в них могут храниться имена файлов.

чтобы все это корректно работало на винде, все пути надо преобразовывать в UTF-16, дергать уникодные версии API, ну и еще обратно в UTF-8 преобразовывать, если функции возвращают строки (например, FindFirstFileW/FindNextFileW).

если всего этого не делать, у тебя будут работать только ascii-имена.

waker ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.