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.

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

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

Ответ на: комментарий от Harald

из того что увидел, condition-variable vista+, shared memory xp+, потоки тоже XP+(ибо TLS) остальное вроде не os-specific и должно завестись

lberserq ()

Что такое plibsys?

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

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

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

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

На винде есть разница. Все функции Windows API продублированы: BlablablablaA принимает и выдает строки в однобайтовых кодировках, UTF-8 и прочий юникод не поддерживается. BlablablablaW принимает и выдает строки UTF-16.

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

У меня есть область применения. Такая библиотека нужна, да, увы, не собирается. Набор разных дистрибов, и все старые. Потому чем меньше зависимостей, тем лучше. Пока что её роль выполняет стандартный Boost.

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

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

я не знаю, что именно там делает py3, но можно, например, посмотреть что делает glib (не привожу ее в пример как хорошую системную абстракцию, но лишь как иллюстрацию кроссплатформенной работы с файлами). на входе/выходе всегда utf8, внутри может быть преобразование в системный формат.

waker ★★★★★ ()

конструктив / субъективщина:

в подобных библиотеках нахрен не нужны списки, хеш-таблицы, и прочий мусор. это не относится к системщине.

нужна возможность собрать библиотеку только с нужными фичами, и выпилить ненужное.

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

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

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

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

Когда несколько лет назад нужен был парсер INI на С, адекватного не нашлось. Возможно, плохо искал или что-то изменилось.

Хэш-функция нужна была для генерации уникальных ftok для IPC. Потом выбор алгоритмов немного расширился. Опять же, я не особо смотрел, есть ли лекговесная либа с основными видами хэшей.

Работа с памятью бывает очень полезна, особенно в некоторых случаях нужен свой кастомный аллокатор. Кроссплатформенный mmap весьма полезен.

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

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

За пакет спасибо! Да, это предупреждение результат изменений в glibc, бегут впереди POSIX.

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

Когда несколько лет назад нужен был парсер INI на С, адекватного не нашлось. Возможно, плохо искал или что-то изменилось.

неплохая библиотека:

https://github.com/ndevilla/iniparser

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

А чем альтернативы не подходят, типа apr? Платформа экзотическая слишком?

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

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

Понятие интересной платформы - весьма субъективное. Мир не ограничивается тройкой Windows/Linux/Mac. Конечно, кому-то не нужно оно, но кому-то будет нужно.

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

https://github.com/ndevilla/iniparser

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

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

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

Где там? В поддерживаемых системах?

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

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

Все верно.

Или поддержка запиливалась в режиме «один раз написали и больше не трогаем»?

Нет, первое утверждение верно.

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

Честно говоря, о том, где конкретно могло использоваться - не знаю. Периодически люди пишут и что-то спрашивают, но я не интересовался спецификой.

Будь оно под пермиссивной лицензией, я бы ещё понял.

LGPL позволяет использовать библиотеку в коммерции.

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

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

Стандартная библиотека используется, по минимуму, если возможно. Вроде старше C89 не должно требоваться, но могу ошибаться.

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

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

Вы правы. Наличие 64-битного целого - требование для сборки. В gcc оно должно было появиться в районе 2.95.x, поэтому только уж что-то совсем древнее не соберется. Ну и, конечно, цели 8-битные контроллеры поддерживать нет :)

HardCode ()

Если ты автор, то подучи английский, а то местами аж корежит.

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

p_file_is_exists -> p_file_exists

:) Это историческое. Но, первый диалект, по идее, тоже употребим, хоть и очень редко.

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

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

Нет, ни в коем случае. Это больше кросс-платформенный слой для выполнения базовых вещей на C. Нет никакой цели создать аналог GLib или другого монстра.

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

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

Да, кросс-компиляция. Есть пример того, как это сделано под BlackBerry 10.

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

Ну C как раз здесь не причем. Просто парень написал довольно солидную либу чисто для себя и своих задач и решил поделиться с миром. Но миру нужно нечно более структурированное и универсализированное. Поэтому кто-то может в теории взять его код и использовать в создании реально удобных и универсальных библиотек.

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

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

Хотя бы тем, что там не используются родные условные переменные и rw-lock на Windows, которые появились на Vista. Поправьте, если ошибаюсь.

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

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

Не пробовал. Если там что-то unix-подобное, то с напильником, скорее всего, заведется.

HardCode ()

Читаю уже третий абзац, так и не понял для чего библиотека

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

т.е что-то вроде SDL, но не ориентированное на игры и графику?

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

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

Представьте себе, да. Не все пишут софт только на новых компиляторах и новых системах.

Но зачем?

Теоретически, если изначально известно, что будет маленький объем данных, то можно не тратиться на балансировку. Но зато будет удобно переключиться на балансировку в случае необходимости. Но больше для интереса и тестирования.

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

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

В чем конкретно возникли проблемы, на какой ОС и с каким компилятором? Желательно лог, чтобы починить.

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

Есть что-то лучше со сравнимым функционалом?

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

На тот момент, когда я смотрел

ничто не стоит на месте..

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

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

Пока нет, но в планах есть интерес.

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

На Windows испольщуются ascii-версии API. По идее, должно работать. Если прямов UTF-8 не пихать.

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

Нет, работы с внутренностями файлов нету.

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

LGPL позволяет использовать библиотеку в коммерции.

все знают, что на iOS нельзя использовать библиотеки под LGPL.

даже если кто-то не пишет сразу под iOS, но есть вероятность ее поддержки в будущем — LGPL сразу нафиг.

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

Но, первый диалект, по идее, тоже употребим

нет. это безграмотно.

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

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

На каком Эльбрусе? Если про ту ОС, которая на базе Debian, то должно собираться (если нет - давайте лог, поправлю). Если вы про 90-микро с древнющей и кастомизированной соляркой типа 2.5.1, то оно там не будет собираться хотя бы по банальной причине того, что отсутствуют некоторые функции (которые там должны быть).

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

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

На XP точно работает. На 98 не проверял, теоретически может завестись.

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

в подобных библиотеках нахрен не нужны списки, хеш-таблицы, и прочий мусор. это не относится к системщине.

Это используется для возврата динамических структур и для внутренностей. Может кому-то заодно пригодится, потому и открыто.

нужна возможность собрать библиотеку только с нужными фичами, и выпилить ненужное.

Вы можете выкинуть из сборки те файлы, что считаете не нужными, только аккуратно с зависимостями. Вообще, библиотека достаточно компактна, что там выкидывать-то?

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

Это очень сильно усложнит портируемость. Да и есть всякие iconv специально заточенные под это.

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

Конечно, если выпилить все из всего, то ничего не остается.

HardCode ()

А как же tcc?

Он хоть и заброшен но с99 вполне тянет)

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

т.е что-то вроде SDL, но не ориентированное на игры и графику?

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

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

ничто не стоит на месте..

Предлагаете сидеть и ждать, пока кто-то напишет?

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

Он не заброшен, смотри дату последнего коммита. Просто релизов давно не было.

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

нет. это безграмотно.

Я не собираюсь вдаваться в подробности разных диалектов и стилей, но такой вариант периодически употребляется, даже в некоторой литературе. Я не спорю, что это не общеупотребительный вариант, но в данном контексте были исторические причины, а не грамматические.

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

все знают, что на iOS нельзя использовать библиотеки под LGPL.

Спасибо, учту. Возможно, надо будет добавить лицензию.

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

все несколько сложнее. типично имена файлов и весь интерфейс в UTF-8

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

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

на входе/выходе всегда utf8

Да, набор байт. glib не гарантирует что там utf-8. По крайней мере когда я ее активно использовал.

внутри может быть преобразование в системный формат.

Именно, я про это же и говорю.

anonymous ()

комбайн

ненужно.

anonymous ()

Да, забыл добавить, что если кто-то собирается использовать с VS2015-2017, то есть готовый порт в репозитории Microsoft на https://github.com/Microsoft/vcpkg

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

вызовы BlablablablaА конвертятся в BlablablablaW( которые в свою очередь конвертятся в вызовы NtBlablabla) т.к на уровне NtBlablablabla используется только utf16 ObjectPath

lberserq ()

я правильно понимаю, что структуры данных не будут корректно работать с shared памятью в ipc?

dinama ()

Спасибо за новость. Проект однозначно нужен!

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