CloudABI's standard C library


NOTE: This project is unmaintained

CloudABI is no longer being maintained. It was an awesome experiment, but it never got enough traction to be sustainable. If you like the idea behind CloudABI, please consider looking into the WebAssembly System Interface (WASI). WASI's design has been inspired by CloudABI.

The author of CloudABI (Ed Schouten) would like to thank all of the people who contributed to this project. Let's hope CloudABI lives on in spirit and influences the way software is designed in the future!

Introducing Nuxi CloudABI

Nuxi CloudABI is an application binary interface for UNIX-like operating systems built around the concept of capability-based security. It offers an environment in which processes can only interact with locally created resources (pipes, socket pairs, shared memory, subprocesses and threads), or global resources (files, sockets) when the process possesses a token granting the process access to the resource (a UNIX file descriptor). In a nutshell, it means that you can run processes directly on top of a UNIX kernel while keeping complete control over the actions the process is allowed to perform.

For example, consider the case where one wants to run a web service. In CloudABI this can be modeled by starting a web server process with the following file descriptors:

  • A listening network socket used to receive incoming HTTP requests,
  • One or more file descriptors to directories containing resources accessible through the web,
  • One or more network sockets connected to backend services used by the web server (e.g., database servers),
  • A file descriptor pointing to a log file.

During its lifetime this web server will never be capable of creating new tokens out of thin air. It may accept incoming network connections on the socket provided on startup, but not create an additional listening socket. It may open files stored within the directories provided on startup, but not access arbitrary paths on the system. This makes CloudABI a lot more secure than the runtime offered by most other UNIX-like systems. A security flaw in this web server will only allow an attacker to compromise the process; not the entire system.

As CloudABI is mostly legacy-free and only needs to implement the features that make sense in an environment that uses capability-based security, it is very small in comparison to other UNIX ABIs. At the time of writing, CloudABI only has 49 system calls. The number of types, datastructures and constants shared between kernelspace and userspace is very low when compared to existing operating systems. This makes it easy to add support for CloudABI executables to existing operating systems. The idea being that software only needs to be compiled once and can be run everywhere.

Nuxi CloudABI aims to become an ideal runtime environment for cluster/cloud computing. As processes become more isolated and less dependent on the host environment, the need for traditional system administration and configuration management will decrease. A cluster can be treated as a single abstract computation service, running processes that are not tied to individual logical operating system instances.

The design of CloudABI is based on the Capsicum lightweight OS capability and sandbox framework developed at the University of Cambridge Computer Laboratory. Nuxi would like to thank its authors for their work.

cloudlibc: Standard C library for CloudABI

cloudlibc is a standard C library built on top of CloudABI. It implements almost all features of the C11 standard, but also a large part of POSIX.1-2008. There are interfaces, however, that have been omitted for one of the following reasons:

  • Safety first.
    cloudlibc aims to make it easier for people to design and implement robust services. C applications may easily be prone to buffer overflows. Functions whose only purpose is to cause such bugs (e.g., gets(), strcpy()) are not implemented. The same holds for functions that are inherently thread unsafe (strtok()), degrade security (srand()), introduce unneeded global state (setlocale()) or offer bad abstraction (signal handlers).

  • Pure capability-based security.
    As access to global namespaces is prohibited, functions such as open(), fopen(), stat(), mkdir() and wait() have been omitted. For filesystem access it is possible to use the POSIX.1-2008 *at() functions instead. In some other cases alternatives have been developed. Fear not: most of these interfaces are either available on systems such as FreeBSD or have been designed in such a way that they can easily be added to existing operating systems.

  • Computing in the cloud.
    Though it is perfectly fine to run CloudABI processes from a command-line on your own workstation, the primary use case remains running networked services in the cloud or on a cluster. Certain concepts (e.g., UNIX user credentials, TTY handling, accounting) make little sense in such an environment.

The source tree is structured as follows:

Building cloudlibc

cloudlibc uses the Bazel build system. A copy of cloudlibc can be built by installing Bazel and running the following command:

bazel build //...

Testing cloudlibc

Unit tests can be run through Bazel as well. Test execution currently assumes the system has native (non-emulated) support for running CloudABI executables (i.e., you're using FreeBSD). These tests can be executed by running the following command:

bazel test //...

Installing cloudlibc

The Bazel build rules provide no support for explicitly installing cloudlibc. Instead of that, it is possible to use Bazel's support for external repositories to use cloudlibc as part of your C/C++ project. Instructions for that can be found on the Bazel Toolchains for CloudABI project page.


Public support

The [email protected] mailing list is used to discuss the development of CloudABI. It is possible to sign up for this mailing list and browse its archive on Google Groups.

An IRC channel called #cloudabi exists on EFnet.

Bugs and pull requests can be submitted through GitHub.

Commercial support

CloudABI has been developed by Nuxi, an IT company based in the lovely city of 's-Hertogenbosch, the Netherlands. Are you interested in receiving commercial support on CloudABI or any of its components? Be sure to get in touch with us at [email protected].

  • segfault on freebsd 11

    segfault on freebsd 11

    Hi! This is really exciting work and I look forward to trying it out.

    I followed the instructions on but I get segfault when running helloworld..

    Running ./_obj/cloudlibc-unittests also gives segfault..

    FreeBSD PC1 11.0-CURRENT FreeBSD 11.0-CURRENT #0 5a410d3(HEAD): Wed Apr 6 11:14:22 PDT 2016 [email protected]:/usr/obj/usr/home/johannes/dev/freebsd/sys/GENERIC-NODEBUG amd64

    opened by johalun 5
  • How to assert()?

    How to assert()?

    Could cloudlibc offer a dassert() macro that accepts a file descriptor for emitting assertion errors? Is this even possible, given that assert() tends to hook deep into C++ throw?

    Alternatively, would be fantastic!

    I suspect this may be possible with dup2(), though I'm not sure how portable that function is.

    opened by mcandre 4
  • Is cloudlibc versioned in any way?

    Is cloudlibc versioned in any way?

    I'm assuming that at some point calls would be added or possibly removed, and one might need preprocessor definitions to understand which version of cloudlibc is available.

    I found the following in include/uv.h but that file is for event handling:

    // Version-checking macros and functions.
    #define UV_VERSION_MAJOR 1
    #define UV_VERSION_MINOR 15
    #define UV_VERSION_PATCH 0
    #define UV_VERSION_SUFFIX "cloudlibc"
    #define UV_VERSION_HEX \
    unsigned int uv_version(void);
    const char *uv_version_string(void);

    Is this official versioning for the entire library?

    opened by jeking3 4
  • i686-unknown-cloudabi-cc: fatal error: 'stdio.h' file not found

    i686-unknown-cloudabi-cc: fatal error: 'stdio.h' file not found

    Hello, I am trying to figure out if I can build 32-bit binaries with the CloudABI toolchain on macOS. I can build and run 64-bit binaries with x86_64-unknown-cloudabi-cc, but when I use the i686 variant, I get an error about a missing header file, stdio.h. I get the same behavior in Docker as well.

    Do I need to install some additional LLVM components, or pass some new flags to the compiler, to get this to work?

    Same error for the aarch64 and armv6 eabihf compilers.

    opened by mcandre 3
  • Tweak inet_ntop's signature to match POSIX.

    Tweak inet_ntop's signature to match POSIX.

    This changes inet_ntop's size parameter from size_t to socklen_t, following POSIX:

    In cloudlibc, these are typedefs for the same type, so there's no effective change here.

    opened by sunfishcode 2
  • setvbuf::iolbf_pipe test fails on Linux

    setvbuf::iolbf_pipe test fails on Linux

    When I run the following command:

    cloudabi-run /usr/x86_64-unknown-cloudabi/bin/cloudlibc-unittests << EOF
    %TAG !,2015:cloudabi/
    tmpdir: !file
      path: tmp-unittest
    logfile: !fd stdout
    nthreads: !!int 1

    one of the test cases fails with the following error:

    [passing tests omitted]
    -> setvbuf::iolbf_pipe
    Test failed
    Statement: ASSERT_EQ(0, ioctl(fds[0], FIONREAD, &nbytes))
    Expected:           0 ==          0 == (0)
    Actual:            -1 == 0xffffffff == (ioctl(fds[0], FIONREAD, &nbytes))
    Location:  src/libc/stdio/setvbuf_test.c:100
    Errno:     52, Function not implemented

    Extra info:

    # Linux version
    [email protected]:~$ uname -a
    Linux vagrant 4.7.0-cloudabi+ #1 SMP Fri Jul 21 12:03:48 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
    # CloudABI version
    [email protected]:~$ apt-cache show x86-64-unknown-cloudabi-cloudlibc 
    Package: x86-64-unknown-cloudabi-cloudlibc
    Version: 0.78-1
    Architecture: all
    Maintainer: [email protected]
    Description: cloudlibc for x86_64-unknown-cloudabi
    Description-md5: 5b87b85f313f06f0c58f75cc46309a30
    Depends: x86-64-unknown-cloudabi-cloudabi, x86-64-unknown-cloudabi-compiler-rt
    Filename: x86-64-unknown-cloudabi-cloudlibc_0.78-1_all.deb
    Size: 1196348
    SHA256: adecbabc32e77944d5c3c463fa73cf0d1b687a89fade4d3d0e91d6467a3ddca9
    Package: x86-64-unknown-cloudabi-cloudlibc
    Status: install ok installed
    Installed-Size: 7719
    Maintainer: [email protected]
    Architecture: all
    Version: 0.78-1
    Depends: x86-64-unknown-cloudabi-cloudabi, x86-64-unknown-cloudabi-compiler-rt
    Description: cloudlibc for x86_64-unknown-cloudabi
    Description-md5: 5b87b85f313f06f0c58f75cc46309a30
    opened by dsprenkels 2
  • Query program name programmatically

    Query program name programmatically

    Lacking the traditional int argc, char **argv entrypoint parameters for querying command line arguments, could program.h provide another way to obtain the name of the program? This is often useful for displaying accurate help command syntax for downstream users.

    opened by mcandre 1
  • CMake having trouble finding sprintf / stdio.h

    CMake having trouble finding sprintf / stdio.h

    Hey, I'm glad to report mild success with CloudABI, building some very simple C and Rust apps! Unfortunately, when I try to use sprintf, I'm getting build errors. Am I doing something wrong?


    My "issue-115" branch of my tonixxx project, in the examples/fewer C project directory:

    Trace (Ubuntu)

    $ CC=x86_64-unknown-cloudabi-cc CXX=x86_64-unknown-cloudabi-c++ cmake .
    $ cmake --build . --config Release
    [ 33%] Linking C executable bin/fewer
    /usr/bin/x86_64-unknown-cloudabi-ld: error: undefined symbol: sprintf
    >>> referenced by fewer.c
    >>>               CMakeFiles/fewer.dir/lib/fewer.c.o:(render_boi)
    clang: error: linker command failed with exit code 1 (use -v to see invocation)
    CMakeFiles/fewer.dir/build.make:120: recipe for target 'bin/fewer' failed
    make[2]: *** [bin/fewer] Error 1
    CMakeFiles/Makefile2:227: recipe for target 'CMakeFiles/fewer.dir/all' failed
    make[1]: *** [CMakeFiles/fewer.dir/all] Error 2
    Makefile:94: recipe for target 'all' failed
    make: *** [all] Error 2

    This is weird, as I am able to access other cloudlibc entities such as dprintf() and fopen() just fine in my main.c source file. Perhaps cmake is getting confused about where libc comes from when dealing with the separate file fewer.c?

    Note: I am running these commands from an Ubuntu 18.04 Bionic Beaver instance in VirtualBox on macOS. When I try to build this CMake project directly on my macOS host, I can't even get the initial CMake cache to complete:

    Trace (macOS)

    $ CC=x86_64-unknown-cloudabi-cc CXX=x86_64-unknown-cloudabi-c++ cmake .
    -- The C compiler identification is Clang 6.0.0
    -- The CXX compiler identification is Clang 6.0.0
    -- Check for working C compiler: /usr/local/bin/x86_64-unknown-cloudabi-cc
    -- Check for working C compiler: /usr/local/bin/x86_64-unknown-cloudabi-cc -- broken
    CMake Error at /usr/local/Cellar/cmake/3.13.2/share/cmake/Modules/CMakeTestCCompiler.cmake:52 (message):
      The C compiler
      is not able to compile a simple test program.
      It fails with the following output:
        Change Dir: /Users/andrew/go/src/
        Run Build Command:"/usr/local/bin/gmake" "cmTC_9b5a3/fast"
        /usr/local/bin/gmake -f CMakeFiles/cmTC_9b5a3.dir/build.make CMakeFiles/cmTC_9b5a3.dir/build
        gmake[1]: Entering directory '/Users/andrew/go/src/'
        Building C object CMakeFiles/cmTC_9b5a3.dir/testCCompiler.c.o
        /usr/local/bin/x86_64-unknown-cloudabi-cc    -o CMakeFiles/cmTC_9b5a3.dir/testCCompiler.c.o   -c /Users/andrew/go/src/
        Linking C executable cmTC_9b5a3
        /usr/local/Cellar/cmake/3.13.2/bin/cmake -E cmake_link_script CMakeFiles/cmTC_9b5a3.dir/link.txt --verbose=1
        /usr/local/bin/x86_64-unknown-cloudabi-cc   -Wl,-search_paths_first -Wl,-headerpad_max_install_names   CMakeFiles/cmTC_9b5a3.dir/testCCompiler.c.o  -o cmTC_9b5a3 
        /usr/local/bin/x86_64-unknown-cloudabi-ld: error: unknown argument: -search_paths_first
        clang-6.0: error: linker command failed with exit code 1 (use -v to see invocation)
        gmake[1]: *** [CMakeFiles/cmTC_9b5a3.dir/build.make:87: cmTC_9b5a3] Error 1
        gmake[1]: Leaving directory '/Users/andrew/go/src/'
        gmake: *** [Makefile:121: cmTC_9b5a3/fast] Error 2
      CMake will not be able to correctly generate this project.
    Call Stack (most recent call first):
      CMakeLists.txt:3 (project)


    I spent some more time configuring my CMakeLists.txt so that the compiler options are closer to the cloudabi compiler defaults, but I am still getting this strange error. Clearly, fewer.c is #includeing the <stdio.h> file, so I am scratching my head wondering what part of this system is dropping the ball.

    One thing I've noticed is that cmake tends to compile executables in multiple stages, compared to using x86_64-unknown-cloudabi-cc directly. Perhaps the compiler is dropping information about where libraries are defined, when object files are built and linked, versus building an executable all at once?

    opened by mcandre 1
  • CloudABI YAML doesn't play well with document delimiters / yamllint

    CloudABI YAML doesn't play well with document delimiters / yamllint

    YAML files are supposed to be able to begin with ---, and yamllint recommends this rule to ensure that many YAML files behave well when concatenated together. However, CloudABI's YAML parsing setup requires its YAML files to begin like %TAG !,2015:cloudabi/, and then a document delimiter and capability spec document can follow.

    Would it be possible to enhance the capability spec so that --- can lead the very beginning of .YML files, matching how other applications process YAML files?

    opened by mcandre 1
  • Add two tests for checking if read() and recv() handle EOF on close/shutdown correctly.

    Add two tests for checking if read() and recv() handle EOF on close/shutdown correctly.

    I found out that this behaviour was incorrect on Cosix, even though all relevant tests were succeeding. There are existing tests for checking this behaviour with poll(), but none yet for a blocking read() and recv(). Perhaps we'll want to add symmetric tests for write() and send() as well.

    Verified by re-introducing the same bug into Cosix and confirming that the tests do fail.

    opened by sgielen 1
  • Add (void) casts to cloudabi_sys_clock_time_get calls.

    Add (void) casts to cloudabi_sys_clock_time_get calls.

    Add (void) to calls to cloudabi_sys_clock_time_get where the return value is unused.

    This allows the cloudabi_sys_* functions to be declared with __attribute__((warn_unused_result)) without introducing warnings in cloudlibc.

    opened by sunfishcode 0
  • storage size for language name too short in newlocale.c

    storage size for language name too short in newlocale.c

    I think, it should be 6, as with 5 the terminating nul char is not taken into account in string like "fr_FR"

    which would be fine if it wasn't checked for it

    opened by sdalu 0
  • Gate the system clock

    Gate the system clock

    cloudlibc offers engineers a tremendous gatekeeper for I/O, writing applications just once in terms of a simple API, and flexibly reconfiguring applications for many different workflows for runtime. Let's extend the same gatekeeping to calls for the current date and time. This is not so much a security measure, as a safety measure:

    Gating the system clock makes it much easier to test complex applications for different clock values, such as several years in the future when important SSL certificates expire, and when 2038 breaks legacy applications. While developers are advised to program in terms of an injectable clock, most applications are not written this way. By intercepting these calls, we offer utility for integration testing this part of the total application input space.

    For many systems, there will come a day when the true date breaks the application, and a convenient way to frequently reset the date to a historical value, will be the only way to resurrect these applications.

    opened by mcandre 0
  • Odd flushing behavior

    Odd flushing behavior

    I'm used to fprintf() intelligently flushing my output streams, e.g. when writing brief text blurbs to stderr in a Read Eval Print Loop application. However, CloudABI appears to wait until the program is terminating to flush. Could we get the flushing behavior closer to a typical GNU/libc fprintf() implicit flush?

    As a workaround, I am doing this for important user feedback sections:

    fprintf(console, "blahblahblah\n");
    #if defined(__CloudABI__)
    opened by mcandre 2
  • More ports!

    More ports!

    cloudlibc has a fantastic number of ports available. Motion to spread support even wider!

    • HardenedBSD (basically FreeBSD with W^X)
    • OpenBSD
    • Alpine (musl libc)
    • Void Linux (musl libc)
    • Busybox uClibC
    • Haiku (missing dprintf, easy enough to shim)
    • SmartOS (needs Gnulib for dprintf, openat)
    • Windows (cygwin)
    • Windows (MVSC), note the use of Windows file handle structures rather than ind fd’s
    opened by mcandre 0
  • No warning when CloudABI entrypoint is missing

    No warning when CloudABI entrypoint is missing

    Porting applications from libc to cloudlibc is hard work, but one problem is particularly pernicious: cloudlibc toolchains do not warn the programmer when he or she forgets basic steps for correctly wiring up the new entrypoint.

    • C: No warning is presented at compilation time when the entrypoint continues to use a traditional libc-style <void|int> main([int argc[, char **argv]]) signature, as opposed to the recommended void program_main(const argdata_t *ad) signature.
    • Rust: No warning is presented at compilation time when the entrypoint function does not query argdata::env::argdata().

    When this happens, the user observes the resulting CloudABI executable emit no output. It would be better for the runtime to present a dummy warning that the entrypoint was misconfigured. Best of all would be to detect this at compile time, and refuse to produce a binary with the wrong entrypoint.

    opened by mcandre 1
  • v0.103(Jan 1, 2019)

  • v0.102(Apr 5, 2018)

    • Remove support for program_spawn_deprecated() and process_wait_deprecated(). As the name suggests, these are deprecated. The libuv based spawning API should be used instead.
    Source code(tar.gz)
    Source code(zip)
  • v0.101(Jan 18, 2018)

  • v0.100(Jan 10, 2018)

    • Catch up with CloudABI changes for system call wrappers: crt0 now provides the bindings.
    • Add program_get_raw_argdata() to extract the raw Argdata buffer. This is useful for the Rust runtime, where we want to provide our own Argdata library.
    • When using main(), don't try to convert data that is likely to be Argdata to string command line arguments.
    • Make file descriptor leak checking slightly more reliable in the unit testing framework.
    Source code(tar.gz)
    Source code(zip)
  • v0.99(Jan 4, 2018)

    This release adds pthread_cond_timedwait_relative_np(). As support for this has also been added to CloudABI itself, this function may make some functions that do relative waits more efficient.

    Source code(tar.gz)
    Source code(zip)
  • v0.98(Dec 30, 2017)

    • Fix a race condition in pthread_create() for detached threads that terminate quickly.
    • Add some more testing coverage for read().
    • Make libuv implementation compatible with libuv 1.18.0.
    Source code(tar.gz)
    Source code(zip)
  • v0.97(Dec 13, 2017)

    • Bring back the old assembly version of longjmp() and setjmp() for AArch64. Clang doesn't support it natively.
    • Unbreak the unit tests on ARMv6 and ARMv7. Call setjmp() in a standards compliant way.
    Source code(tar.gz)
    Source code(zip)
  • v0.96(Dec 11, 2017)

    • Reimplement setjmp() and longjmp() on top of GCC/Clang builtins.
    • Fix fputws() to return -1 instead of WEOF.
    • Make <fenv.h> a bit more complete for RISC-V.
    Source code(tar.gz)
    Source code(zip)
  • v0.95(Dec 5, 2017)

    • Add SPDX license tags to the source files.
    • Add some basic fixes needed to support RISC-V.
    • Fix some compiler warnings on ARM, etc.
    • Rework the way basic C types and limits are defined.
    • Add more testing coverage for blocking on sockets.
    Source code(tar.gz)
    Source code(zip)
  • v0.93(Nov 2, 2017)

  • v0.92(Nov 1, 2017)

  • v0.91(Oct 28, 2017)

    • No longer depend on fields in cloudabi_event_t that will be removed from the CloudABI specification.
    • Add uv_disable_stdio_inheritance() for Node.js.
    • Add uv_tty_reset_mode() for Node.js.
    Source code(tar.gz)
    Source code(zip)
  • v0.90(Oct 27, 2017)

    • Addition of uv_*_s structure tags.
    • Addition of uv_pipe_t::ipc.

    These features are not officially documented yet, but seem to be used by Node.js.

    Source code(tar.gz)
    Source code(zip)
  • v0.89(Oct 25, 2017)

  • v0.88(Oct 25, 2017)

    This release contains an implementation of <uv.h> that is a lot more robust than before. Stream I/O should now mostly work, including file descriptor passing.

    Source code(tar.gz)
    Source code(zip)
  • v0.87(Oct 21, 2017)

  • v0.86(Oct 20, 2017)

    • Add an event loop to the C library that shares the same API as libuv, or at least the parts compatible with CloudABI's security model.
    • Remove the pdfork() function. We're going to work towards having an environment where we can spawn subprocesses, as opposed to forking the execution of a running process. This has the advantage that it improves security and makes programming easier.
    Source code(tar.gz)
    Source code(zip)
jkds is a modern header-only C++20 library that complements the standard library.

jkds is a modern header-only C++20 library that complements the standard library. It provides generic atypical data structures, ergonomic functional programming abstractions, and then some.

Alberto Schiabel 5 May 24, 2022
Bionic BSD-3-ClauseBionic - Google's standard library, developed for Android. BSD-3-Clause

bionic bionic is Android's C library, math library, and dynamic linker. Using bionic as an app developer See the user documentation. Working on bionic

Android Open Source Project 552 Sep 28, 2022
CloudABI's standard C library

NOTE: This project is unmaintained CloudABI is no longer being maintained. It was an awesome experiment, but it never got enough traction to be sustai

Nuxi 272 Sep 15, 2022
libcu++: The C++ Standard Library for Your Entire System

libcu++, the NVIDIA C++ Standard Library, is the C++ Standard Library for your entire system. It provides a heterogeneous implementation of the C++ Standard Library that can be used in and between CPU and GPU code.

NVIDIA Corporation 2k Sep 29, 2022
EASTL stands for Electronic Arts Standard C++ Template Library

EASTL stands for Electronic Arts Standard Template Library. It is an extensive and robust implementation that has an emphasis on high performance.

Electronic Arts 6.7k Oct 2, 2022
An open source standard C library that includes useful functions && (Reimplementation of libc functions + own functions).

?? LIBFT-42 : Artistic view of LIBC: ?? HOW DOES IT FEEL HAVING YOUR OWN LIB: SUBJECT : ENGLISH PDF ℹ️ What is LIBFT : This project aims to code a C l

Abdessamad Laamimi 11 Sep 21, 2022
Your standard library for metaprogramming

Boost.Hana Your standard library for metaprogramming Overview #include <boost/hana.hpp> #include <cassert> #include <string> namespace hana = boost::h 1.4k Oct 3, 2022
Reimplementation of some of the Standard C Library functions.

42-libft Reimplementation of some of the Standard C Library functions. This repository contains some of the standard library C functions. List of avai

Lavrenova Maria 6 Sep 29, 2022
STXXL: Standard Template Library for Extra Large Data Sets

STXXL is an implementation of the C++ standard template library STL for external memory (out-of-core) computations

STXXL 431 Sep 24, 2022
MSVC's implementation of the C++ Standard Library.

Microsoft's C++ Standard Library This is the official repository for Microsoft's implementation of the C++ Standard Library (also known as the STL), w

Microsoft 8.2k Oct 3, 2022
mlibc is a C standard library

mlibc is a C standard library Official Discord server: Design of the library Directory Purpose options/ (More or less) OS-i

The Managarm Project 524 Sep 29, 2022
A standard conforming C++20 implementation of std::optional.

A standard conforming C++20 implementation of std::optional.

null 31 Aug 24, 2022
Library that simplify to find header for class from STL library.

Library that simplify to find header for class from STL library. Instead of searching header for some class you can just include header with the class name.

null 6 Jun 7, 2022
D++ Extremely Lightweight C++ Discord Library

D++ An incredibly lightweight C++ Discord library This project is in alpha stages of development. Completed so far: Websocket connection with heartbea 501 Oct 1, 2022
Single-header header-only C++11 / C++14 / C++17 library for easily managing set of auto-generated type-safe flags.

Single-header header-only C++11 / C++14 / C++17 library for easily managing set of auto-generated type-safe flags. Quick start #include <bitflags/bitf

Marin Peko 72 Aug 24, 2022
expected lite - Expected objects in C++11 and later in a single-file header-only library

expected lite: expected objects for C++11 and later expected lite is a single-file header-only library for objects that either represent a valid value

Martin Moene 232 Sep 28, 2022
Guidelines Support Library

GSL: Guidelines Support Library The Guidelines Support Library (GSL) contains functions and types that are suggested for use by the C++ Core Guideline

Microsoft 5.2k Oct 5, 2022
gsl-lite – A single-file header-only version of ISO C++ Guidelines Support Library (GSL) for C++98, C++11, and later

gsl-lite: Guidelines Support Library for C++98, C++11 up metadata build packages try online gsl-lite is an implementation of the C++ Core Guidelines S

gsl-lite 756 Sep 30, 2022
C++11 metaprogramming library

Mp11, a C++11 metaprogramming library Mp11 is a C++11 metaprogramming library based on template aliases and variadic templates. It implements the appr 178 Oct 2, 2022