# plibsys, a portable C system library that keeps to native calls

> saprykin/plibsys is a cross-platform C library with zero third-party dependencies, covering threads, mutexes, read-write locks, semaphores, shared memory, sockets over TCP, UDP and SCTP with IPv4 and IPv6, hash functions, balanced binary trees, an INI parser and a time profiler. It achieves portability by using a different native model per platform rather than by emulating one.

**saprykin/plibsys** — Highly portable C system library: threads and synchronization primitives, sockets (TCP, UDP, SCTP), IPv4 and IPv6, IPC, hash functions (MD5, SHA-1, SHA-2, SHA-3, GOST), binary trees (RB, AVL) and more. Native code performance.

- Repository: https://github.com/saprykin/plibsys
- Stars: 769 · Forks: 95
- Language: C
- License: MIT
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/saprykin-plibsys

## The design choice: native models instead of emulation

plibsys is a cross-platform system C library with some helpful routines, and the first line of the About section states the two constraints that shape everything: zero third-party dependencies and only native system calls.

The interesting design decision is stated later in the README, under the idea of achieving maximum native performance on each platform. The library defines several implementation models and picks one per platform rather than emulating a lowest common denominator.

Threading models cover POSIX, Solaris, OS/2, BeOS, AtheOS, AmigaOS and Win32. IPC models cover POSIX, System V, OS/2, AmigaOS and Win32. The time profiler has models for POSIX, Solaris, Mach, OS/2, BeOS, AmigaOS, Win32 and a generic fallback. Directory iteration uses POSIX, OS/2 and Win32 models, and shared library loading has POSIX, HP-UX, OS/2, BeOS, AmigaOS and Win32 variants. Atomic operations have sync, C11, DECC, Win32 and simulated models, and sockets are BSD with Win32 support.

That list is the answer to how a library stays portable without being slow. On a POSIX system you get the POSIX calls, on Windows you get the Win32 calls, and on a platform with no native implementation you get a generic or simulated fallback. The cost is that the library has many code paths to test, and the platform matrix is where the maintenance effort goes.

The feature set is what you would expect from a system library: platform independent data types, threads, mutexes, condition variables, read-write locks, system-wide semaphores and shared memory, an optimised spinlock, atomic operations, socket support for UDP, TCP and SCTP over IPv4 and IPv6, the MD5, SHA-1, SHA-2, SHA-3 and GOST R 34.11-94 hash functions, BST, red-black and AVL binary trees, an INI file parser, a high resolution time profiler, file and directory helpers, shared library loading, and the usual routines for linked lists, strings and hash tables.

## The platform matrix is the real specification

For a portability library, the platform list is the product, and plibsys's is unusually long.

The desktop platforms tested are GNU/Linux, macOS, Windows, Cygwin and MSYS, FreeBSD, NetBSD and OpenBSD, DragonFlyBSD, Solaris, AIX, HP-UX, Tru64, OpenVMS, OS/2, IRIX, QNX Neutrino, UnixWare 7, SCO OpenServer 5, Haiku, Syllable, BeOS and AmigaOS.

The mobile list covers iOS, tvOS, visionOS and watchOS, Android, and BlackBerry 10. The README adds that it should also work on other Unix-like systems with or without minimal efforts.

The compiler list is the other half of that. MSVC from 2003 onwards on x86, x64 and AArch64, MinGW, Open Watcom, Borland, GCC across an architecture list that includes PPC32be, PPC64 in both endiannesses, IA-64, Alpha, HPPA, MIPS, AArch32 and 64, SPARC, S390x, LoongArch64 and RISC-V, Clang over a similar set, Intel, QCC, Oracle Solaris Studio, MIPSpro, XL C, DEC C, PGI, Cray and LCC for the e2k architecture.

Two details in that list are worth pausing on. Cray and LCC for e2k mean this library has been built on architectures that no longer exist commercially, which tells you something about its age and about the author's commitment to keeping old targets alive. And the presence of both DEC C and DECC atomic models suggests the library has been maintained across hardware transitions rather than rewritten.

The README states the library is fully covered with unit tests and that it was tested on those platforms, and the CI badges at the top of the README reflect GitHub Actions, AppVeyor, SonarCloud, Coverity and Codecov, so the testing claim is backed by several independent services rather than one.

## Building it and what the build produces

The building section is short: use CMake to build plibsys for the target platform, with a note that OpenVMS users should look in the platforms/vms-general directory.

That single sentence conceals a fair amount of work, since a build that has to produce a shared library with a working ABI across twenty operating systems needs per-platform handling. The repository layout shows where that lives: a cmake/ directory for the CMake modules, a platforms/ directory for the platform-specific pieces, and a 3dparty/ directory.

The 3dparty/ directory deserves a note. The README says the library has zero third-party dependencies, and that claim is about what your build pulls in, not about what the project works with internally. Coverity and SonarCloud appear as badges, and some portability projects vendor analysis tools or reference implementations in a directory like that.

The rest of the layout is conventional for a mature C library: src/ for the code, tests/ for the unit tests, scripts/ for build and release helpers, a Doxyfile.in for the generated documentation, a COPYING file for the licence text, an AUTHORS file, a NEWS file for release notes, an appveyor.yml for the Windows CI, and a codecov.yml.

Documentation for the latest stable version is published through GitHub Pages, and the README points to the project wiki for more information. Both are worth checking before you start, because the header-level API documentation is generated by Doxygen and the wiki is where the narrative guidance lives.

The licence is MIT, which is permissive and causes no friction for commercial use. The last push was on 2026-07-17.

## Release cadence and the question of maintenance

The release history is the fact that most affects a decision here, and it deserves a direct statement. The listed releases are 0.0.3 in May 2017, 0.0.4 in May 2018 and 0.0.5 in November 2024.

A version number of 0.0.5 tells you the project does not use semantic versioning, or has not adopted it, and the gap between the second and third releases is six years. The last push was on 2026-07-17, so the code is still being touched, but there has been no tagged release in nearly two years.

For a library that is mostly stable C with a broad portability matrix, that is less alarming than it sounds. A library with a large surface of platform-specific code is not the kind of thing that wants frequent releases, and the absence of a release does not mean the code is broken. But it does mean that if you pick this up, you are picking up master, not a tagged version with a support commitment behind it.

That is the honest framing for the whole project. plibsys is a long-lived personal effort with a serious portability scope, an MIT licence, a comprehensive test suite and a great deal of accumulated knowledge about how to call the primitives of two dozen operating systems. What it does not have is the cadence or the release discipline that would make it an easy choice for a team that wants a supported dependency.

The practical recommendation follows from that. If you need something on a mainstream platform, use the platform. If you need something on OpenVMS or QNX or OS/2 and nothing else will do, this is a serious candidate and the alternative is writing the same code yourself.

## How it compares with POSIX and with portable C libraries

The comparison with plain POSIX is unavoidable and mostly unfavourable to plibsys on any mainstream platform. POSIX threads, POSIX sockets and POSIX shared memory are already in your compiler's headers, better documented, and maintained by the platform vendor. Wrapping them adds a layer without removing a dependency.

The comparison with the portable C libraries, the ones that abstract sockets and threads behind a uniform API, is more interesting. The difference in approach is that those libraries emulate. A uniform threads implementation typically maps onto pthreads where available and onto a Windows implementation otherwise, with a thin abstraction layer on top. plibsys goes further in choosing a different native model per platform for each subsystem, so on Windows you get Win32 threads rather than a pthreads emulation layer.

What that buys is performance and behaviour that matches the operating system, which matters when you are writing something that has to behave like a native application on an unusual platform. What it costs is that the library's own API is not a small common denominator, so the surface you can rely on across all platforms is narrower than a uniform abstraction's.

The comparison with writing the code yourself is the one that comes up most often for this kind of library, and the honest answer is that for anything on Linux, macOS or Windows, you should write it yourself. The code is not that long, the platform documentation is better than any wrapper's, and you inherit no third-party code to maintain. plibsys pays for itself when the target list includes platforms you have never built on, where its years of accumulated portability knowledge are worth more than the code.

The hash functions and balanced tree implementations are a separate category. Those are algorithm implementations rather than system wrappers, and there the comparison is with well-known single-purpose libraries rather than with the platform. SHA-3 and GOST support in particular is a specific choice you would otherwise assemble yourself.

## Conclusion

Adopt plibsys if you are writing portable C that has to run on an unusual operating system, and you want threads, sockets and IPC without pulling in a third-party library. Skip it if you are on a single modern platform, because the platform's own headers already cover the same ground with better documentation. Verify first by checking the platforms and compilers lists against your targets, and by running the library's unit test suite on the platforms you actually ship to, since the README claims full unit test coverage across them.

## FAQ

### What does plibsys provide?

A cross-platform C system library with no third-party dependencies offering platform independent data types, threads, mutexes, condition variables, read-write locks, semaphores, shared memory, an optimised spinlock, atomic operations, TCP, UDP and SCTP sockets over IPv4 and IPv6, MD5, SHA-1, SHA-2, SHA-3 and GOST hashing, BST, red-black and AVL trees, an INI parser, a time profiler and shared library loading.

### Which operating systems does plibsys support?

The tested list includes GNU/Linux, macOS, Windows, Cygwin, MSYS, FreeBSD, NetBSD, OpenBSD, DragonFlyBSD, Solaris, AIX, HP-UX, Tru64, OpenVMS, OS/2, IRIX, QNX Neutrino, UnixWare 7, SCO OpenServer 5, Haiku, Syllable, BeOS and AmigaOS, plus iOS, tvOS, visionOS, watchOS, Android and BlackBerry 10 on mobile.

### How does plibsys achieve portability without emulating?

It defines several implementation models and selects the native one per platform. Threading has POSIX, Solaris, OS/2, BeOS, AtheOS, AmigaOS and Win32 models, IPC has POSIX, System V, OS/2, AmigaOS and Win32, atomics have sync, C11, DECC, Win32 and simulated variants, and sockets are BSD with Win32 support.

### How do I build plibsys?

Use CMake to build it for the target platform. OpenVMS users should look in the platforms/vms-general directory. The repository holds a cmake/ directory for the build modules and a platforms/ directory for the platform-specific code.

### How often is plibsys released?

The listed releases are 0.0.3 in May 2017, 0.0.4 in May 2018 and 0.0.5 in November 2024, with the last push on 2026-07-17. The version numbers do not follow semantic versioning, and there has been no tagged release since 2024.

## Sources

- [Issues](https://github.com/saprykin/plibsys/issues)
- [License: MIT](https://github.com/saprykin/plibsys/blob/master/LICENSE)
- [README](https://github.com/saprykin/plibsys/blob/master/README.md)
- [Releases](https://github.com/saprykin/plibsys/releases)
- [saprykin/plibsys on GitHub](https://github.com/saprykin/plibsys)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/saprykin-plibsys