A reflective enum implementation for C++


wise_enum Build Status Build status

Because reflection makes you wise, not smart

wise_enum is a standalone smart enum library for C++11/14/17. It supports all of the standard functionality that you would expect from a smart enum class in C++:

  • Tells you the number of enumerators
  • Lets you iterate over all enum values
  • Converts string to enum, and enum to string
  • Does everything in an idiomatic C++ way (friendly to generic programming, compile time programming, etc)


Let's look at a bit of code. You can declare an enum like this:

// Equivalent to enum Color {GREEN = 2, RED};

You can also declare an enum class instead of an enum, specify the storage explicitly, declare an enum nested inside a class, or even adapt an already declared enum:

// Equivalent to enum class MoreColor : int64_t {BLUE, BLACK = 1};
WISE_ENUM_CLASS((MoreColor, int64_t), BLUE, (BLACK, 1))

// Inside a class, must use a different macro, but still works
struct Bar {

// Adapt an existing enum you don't control so it works with generic code
namespace another_lib {
enum class SomebodyElse { FIRST, SECOND };
WISE_ENUM_ADAPT(another_lib::SomebodyElse, FIRST, SECOND)

You can ask the enum how many enumerators it has:

static_assert(wise_enum::size<Color> == 2, "");

Iterate over the enumerators:

std::cerr << "Enum values and names:\n";
for (auto e : wise_enum::range<Color>) {
  std::cerr << static_cast<int>(e.value) << " " << e.name << "\n";

Convert between strings and enums:

// Convert any enum to a string
std::cerr << wise_enum::to_string(Color::RED) << "\n";

// Convert any string to an optional<enum>
auto x1 = wise_enum::from_string<Color>("GREEN");
auto x2 = wise_enum::from_string<Color>("Greeeeeeen");

assert(x1.value() == Color::GREEN);

Check whether something is a wise enum at compile time:

static_assert(wise_enum::is_wise_enum_v<Color>, "");
static_assert(!wise_enum::is_wise_enum_v<int>, "");
enum flub { blub, glub };
static_assert(!wise_enum::is_wise_enum_v<flub>, "");


It has a few notable design choices.

First, when you use one of the macros to declare your enum, what gets declared (among other things) is exactly the vanilla enum (or enum class) that you would expect. Not an enum like class, or anything like that. That means that wise_enums can be used exactly like regular enums in non-reflective contexts, because they are regular enums. They can be used as non-type template parameters, and they can be used in switch case statements, unlike any user defined type. This also means that upgrading a regular enum already widely used (non-reflectively) in your codebase to a wise enum is never a breaking change. No strange behavior, or edge cases, when used with other third party libraries (e.g. serialization), or standard library type traits.

Second, all the functionality in defining enums is preserved. You can define enum or enum classes, set storage explicitly or let it be implicit, define the value for an enumeration, or allow it to be determined implicitly. You can also define enums nested in classes, which isn't supported in some smart enum libraries.

Third, it's quite compile-time programming friendly. Everything is constexpr, and a type trait is provided. This makes it easy to handle wise enums in a specific way in generic code. For example, if you have a logger, it can't intelligently log a vanilla enum without more information, but it can log a wise enum, so you can use the type trait to handle them differently (with no performance cost of course).

Fourth, it's careful with regards to performance and generated assembly. It makes zero heap allocations and does zero dynamic initialization, and does not use exceptions. The enum -> string is an optimal switch-case. String -> enum is currently a linear search; this may be changed in the future (most alternatives are not trivial to implement without doing heap allocations or dynamic initialization).

Quick Comparison of Alternatives

The best known alternative is probably Better Enums. The biggest issue with Better Enums is simply that its macros don't actually create enums or enum classes, but enum like classes. This carries all of the disadvantages discussed in the previous section, and for me was just a deal breaker. There are also more minor issues like not being able to define a nested enum, having a lower default enumeration limit. Conversely, I'm not aware of any advantages, except one: it does support C++03, which wise enum never will, so it's a good choice for older codebases.

A recent interesting alternative is Meta Enum. This does declare actual enum/enum classes. As benefits, it doesn't have any limit on the number of enumerations by design, and it doesn't require different macros for declaring enums nested inside classes. As far as I can tell though, the approach means that it can't support switch case generation (e.g. for to_string), nor can it support 11. It currently only seems to support 17 but 14 support may be possible.

As far as I saw, neither library has something like the adapt macro, though I think either one could add it pretty easily. There are other implementations, but most of the ones I've seen are very clearly very short projects, lacking support for basic features (e.g. controlling enum values) and documentation.

Overall, I feel like wise enum is the best choice for an enum library for a typical, modern C++ codebase.

If any of this information is incorrect, please let me know and I'll make correcting it the highest priority.

Version differences

Wise enum tries to target each language version idiomatically. In 11, template variables, which are the recommended interface in 14/17 are not available so using the typical class template static interface instead is necessary. Many functions lose constexpr in 11. The difference between 14 and 17 is mostly in the types used, discussed in the next section.

Types and Customizations

There are two types that you can customize in wise_enum, by defining macros: the optional type, and the string type.

Type 11/14 default 17 default customize macro type alias
optional wise_enum::optional std::optional WISE_ENUM_OPTIONAL_TYPE wise_enum::optional_type<T>
string const char * std::string_view WISE_ENUM_STRING_TYPE wise_enum::string_type

If you only support 17, the defaults should be fine. If you're on 11/14, the defaults are fine as well, but if you want to be forward compatible I'd consider rounding up a string_view implementation somewhere and using that. Otherwise, since const char* and string_view don't have the same interface, you may have breakages when upgrading. Finally, if you're supporting both 11/14 and 17 I'd definitely define both macros so the same type is used in your builds.

You can define the macro either in your build system, or by having a stub header that defines them and then includes wise_enum.h, and only including via the stub.

You can also customize the use of exceptions. If you use the CMake option NO_EXCEPTIONS or otherwise define the macro WISE_ENUM_NO_EXCEPT, then wise_enum should be fully compatible with -fno-exceptions. The API never directly throws exceptions anyhow; the only change in behavior is that the provided optional (and compact_optional) will abort rather than throw on value() calls if the optional is empty, similar to the behavior of most (all?) standard library optional implementations when exceptions are disabled.

Extra Features

Over time I'd like to leverage some of the capabilities of wise enum to do other useful enum related things.

Compact optional

I have a compact optional implementation included now in wise enum. The key point is that it uses compile time reflection to statically verified that the sentinel value used to indicate the absence of an enum, is not a value used for any of the enumerators. If you add an enumerator to an enum used in a compact optional, and the value of the enum is the sentinel, you get a compilation error.

Switch case "lifts"

One problem where C++ gives you little recourse is when you have a runtime value that you want to lift into a compile time value. Consider the following:

template <MyEnum E>
class MyDerived : MyInterface {...};

unique_ptr<MyInterface> make(MyEnum e);

It's hard to write make without boilerplate in the general case. You need to manually switch case over all enumerator values, and in each case put the compile time constant into the template. Wise enum will shortly (exact interface being worked out) provide a facility that takes an enum and a lambda, does the switch case over all values internally, and calls the lambda making the enum available as a compile time constant.

Coming soon!

Enum Sets

Planned for the future.


There are some known limitations:

  • If there are enumerators with the same value, then to_string will not work. You can declare the enum and use all the other API. This is both because it doesn't jive at all with the implementation, and even conceptually it's not clear how you would handle a conversion to string since multiple strings would be associated with the same value.
  • By default, you are limited to 256 enumerations. If you need more, simply run the create_generated script to create a file with as many as you need, and replace wise_enum_generated with that file. The default limit may be raised or lowered based on feedback. An alternative solution here would be to create headers in advance that raise this number, but leave the onus on the user to include them (so users who don't need a large number aren't slowed down)


Why didn't I use BOOST_PP?

I started with it, but the limit on sequences was very disappointing (64) and there didn't seem to be any easy way to change it. So then I started down the codegen route, and once there, I wasn't using very much. I know there are always people who prefer to avoid the dependency, so I decided to drop it.

  • Actually uses exceptions

    Actually uses exceptions

    The readme says wise_enum doesn't use any heap or exceptions, which would be great for embedded applications. Unfortunately it's not true -- std::optional::value() and wise_enum::optional::value() throw bad_optional_access.

    opened by mje-nz 9
  • Fix expansion of `__VA_ARGS__` macro argument in MSVC

    Fix expansion of `__VA_ARGS__` macro argument in MSVC

    This merge request fixes issues with variadic macro argument expansion in MSVC. The issue is that when passing __VA_ARGS__ as an argument to another macro, MSVC expands __VA_ARGS__ after passing, whilst gcc expands it before.

    Issue #31 can be closed.

    opened by samangh 8
  • add cmake build support

    add cmake build support

    Hi there,

    I am finding wise_enum very useful but we have standardised on cmake and hunter as a build system and dependency manager.

    In order to make that seamless, it's helpful to build a standard cmake script which supports installing the product and the config files.

    This PR addresses only this. No code as been changed.

    opened by madmongo1 7
  • Don't unconditionally return `nullptr` from wise_enum_detail_to_string

    Don't unconditionally return `nullptr` from wise_enum_detail_to_string

    Currently wise_enum_detail_to_string unconditionally returns nullptr, if the enum value passed to to_string is not found (which is easy quite easy to do, for example default-constructing an enum class not starting at 0 or using a partially-adapted 3rd party enum).

    This causes a problem, however, with C++17, as the library defaults to using std::string_view. While GCC 8.2 seems to work fine, both GCC 9 trunk and Clang 7 segfault on execution.

    The problem is likely the following: As per 24.2.1 [string.view.cons], constructing from a nullptr uses the implicit one-argument constructor taking charT const*, which in turn relies on traits::length to get the size of the passed string.

    24.2.1 [char.traits.require] now states, that length(p) Returns: the smallest i such that X::eq(p[i],charT()) is true. So even for i == 0, eq(p[i], charT()) must be checked (although GCC 8.2's implementation seems to bail out here), which results in nullptr being dereferenced.

    So far, I see two ways of getting about this: either return a default-constructed string_type (which is a 0-length nullptrd for string_view and nullptr for char const* or introduce a constexpr string_type invalid_enum_value_string variable, which defaults to a default-constructed string_type and is customizable via a macro.

    opened by JonasProgrammer 7
  • Visual C++ limits macro arguments to 127

    Visual C++ limits macro arguments to 127

    Both examples fail to compile on Visual C++ 16.0 P1 because macro arguments are limited to 127:

    > cl /std:c++latest /permissive- example.x.cpp
    Microsoft (R) C/C++ Optimizing Compiler Version 19.20.27027.1 for x64
    Copyright (C) Microsoft Corporation.  All rights reserved.
    wise_enum_generated.h(30): fatal error C1112: compiler limit: 
        '258' too many macro arguments, only '127' allowed
    opened by personalmountains 7
  • Remove throw via macro

    Remove throw via macro

    Pull request to solve #15 If WISE_ENUM_NO_EXCEPTIONS macro is defined, .value() functions now blindly return the contained object, it is up to the user to make sure there is something to get.

    opened by ilazaric 5
  • Feature: Check if a given value equals one of the enums

    Feature: Check if a given value equals one of the enums

    I would like check if a value I have is equivalent to one of my enums.

    For example, assume a function contains, I would expect it to behave as:

    WISE_ENUM(Color, (GREEN, 2), RED);
    static_assert(wise_enum::contains<Color>(1) == false);
    static_assert(wise_enum::contains<Color>(2) == true);
    static_assert(wise_enum::contains<Color>(3) == true);
    opened by peter-moran 4
  • Converting to / from index

    Converting to / from index

    There is range and size. Is there also a direct way to get the n'th enum value, and vice-versa, the index in the range for a given enum value?

    I guess both could be done easily by iterating over the range, but I was woundering if there is direct way.

    opened by NikolausDemmel 4
  • Put big WARNING Sign on the main page: Won't work with Visual Studio!

    Put big WARNING Sign on the main page: Won't work with Visual Studio!

    I was looking for a enum which gives me little more capabilities like the to_string function. I found wise_enum. The main page (readme.md) looked promising.

    I took the effort to check it out in my programm. First I stumled over the __cpluplus thing, then I had to adjust compiler switches, then I stumbled over the 127 macro arguments thing. And after all the hazzle I looked into the Issues and they were all already there.

    Please: It does not work in VisualStudio. You got feedback about it. Please place a big red WARNING note that on the main page. Please spare other people with VisualStudio the effort to try to use it. Sorry, I'm really a bit pissed...

    opened by huberp 3
  • string_type is `string_view` for C++17 and `const char *` for C++20

    string_type is `string_view` for C++17 and `const char *` for C++20

    Rather than checking for an exact match for the C++ version string of #if __cplusplus == 201703L, it should at least check with >=. Better still would be to check #ifdef __cpp_lib_string_view, as that will check exactly what you are trying to test.

    opened by davidstone 3
  • Does not seem to compile in VS2019

    Does not seem to compile in VS2019

    I can't get wise_enum to work in Visual Studio 2019 16.1.4..I'm using version 3.0.0.

    My code:

    WISE_ENUM(MyEnum, MyEnumCaseOne, MyEnumCaseTwo)

    Error output:

    1>------ Build started: Project: WiseEnumTest_App, Configuration: Debug x64 ------
    1>E:\WiseEnumTest\Source\Main.cpp(3,1): warning C4003:  not enough arguments for function-like macro invocation 'WISE_ENUM_IMPL_ARG_N'
    1>E:\WiseEnumTest\Source\Main.cpp(3,1): error C2143:  syntax error: missing '}' before '('
    1>E:\WiseEnumTest\Source\Main.cpp(3,1): error C2143:  syntax error: missing ')' before ','
    1>E:\WiseEnumTest\Source\Main.cpp(3,1): error C2059:  syntax error: ')'
    1>E:\WiseEnumTest\Source\Main.cpp(3,1): error C2143:  syntax error: missing ';' before '}'
    1>E:\WiseEnumTest\Source\Main.cpp(3,1): error C2059:  syntax error: '}'
    1>E:\WiseEnumTest\Source\Main.cpp(3,1): error C2059:  syntax error: '>'
    1>E:\WiseEnumTest\Source\Main.cpp(3,1): error C2062:  type 'unknown-type' unexpected
    1>E:\WiseEnumTest\Source\Main.cpp(6,34): error C2059:  syntax error: 'public'
    1>E:\WiseEnumTest\Source\Main.cpp(7,1): error C2143:  syntax error: missing ';' before '{'
    1>E:\WiseEnumTest\Source\Main.cpp(7,1): error C2447:  '{': missing function header (old-style formal list?)
    1>E:\WiseEnumTest\Source\Main.cpp(97,1): error C2061:  syntax error: identifier 'WiseEnumTestApplication'
    1>Done building project "WiseEnumTest_App.vcxproj" -- FAILED.
    ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

    I've tried adding the /permissive- compiler flag, but I still get the same errors. I've also tried running create_generated.py to generate just 125 cases, but still get the same error.

    Thank you again for the great work, and any help would be appreciated 😊

    opened by martinfinke 3
  • Bug compiler does not seem to be correctly resolving wise enum

    Bug compiler does not seem to be correctly resolving wise enum

    Perhaps my implementation is wrong but I have something like the following:

    // myclass.hpp
    class MyClass {
        WISE_ENUM_CLASS_MEMBER(Type, int64_t, MyENUM);
        Type type_ = Type::MyENUM;
        MyClass(const Type type);
        MyClass() : MyClass(type_) {};
    // myclass.cpp
    MyClass::MyClass(const Type type) {
      std::court << "type " << wise_enum::to_string(type) << " and type_ " << wise_enum::to_string(type_) << std::endl;
      type_ = type;

    Running this with a default instance of MyClass leads to output like so:

    int main() {
      MyClass obj;
      return 0;
    type  and type_ MyENUM

    Where there is no string content for type?

    opened by JoshuaSBrown 2
  • Check if underlying type is in enum

    Check if underlying type is in enum

    Add runtime check function if a value of underlying type is in enum. verify_enum I believe trivial with your code. Thanks for excellent library, can do a PR if you would add me

    opened by szavadsky 0
  • is_wise_enum_class and is_wise_enum_vanilla?

    is_wise_enum_class and is_wise_enum_vanilla?

    I am using wise_enum library and i have a requirement to distinguish if something is an enum class or plain vanilla enum at compile time. wise enum provides a way to check if something is a wise_enum, which also implicitly means that it can tell us if something is an enumeration type. This is because wise_enum creates an actual scoped or unscoped class.

    I looked into C++ standard to check if there is an existing type-trait that distinguishes between enum class and vanilla enum. i found : std::is_enum // again does not distinguish between scoped and unscoped enums std::is_scoped_enum // exactly what i need, but unfortunately it's proposed for C++23

    I think i am going to end up implementing this on my own. But i think it adds value to wise_enum also if it has this kind of type introspection available as C++23 is still a few years i think.

    I am happy to add this enhancement to WISE_ENUM as well.

    Interested in some feedback here!


    opened by sahilsharma-github 0
  • Visual Studio: Require new preprocessor

    Visual Studio: Require new preprocessor

    The conversion between enum and string doesn't seem to work using Visual Studio. The reason is that the preprocessor behaves incorrectly, so the string for an enum value becomes "WISE_ENUM_IMPL_IIF_1 (WISE_ENUM_IMPL_FIRST_ARG (SomeEnumValue, 0), (SomeEnumValue, 0))" instead of "SomeEnumValue".

    This can be solved by enabling the new conforming preprocessor. wise_enum could check this at compile-time:

    #ifdef _MSC_VER
    #error "The traditional, non-standard preprocessor is not supported. From Visual Studio 15.8 through 16.4, add the '/experimental:preprocessor' compiler option. From Visual Studio 16.5 onwards, add the '/Zc:preprocessor' compiler option."
    // _MSVC_TRADITIONAL is not defined, check from_string/to_string using a test enum:
    namespace detail {
        enum class TestEnum { SomeTestValue };
    static_assert(detail::strcmp(to_string(detail::TestEnum::SomeTestValue), "SomeTestValue") == 0
                      && from_string<detail::TestEnum>("SomeTestValue") == detail::TestEnum::SomeTestValue,
                  "The traditional, non-standard preprocessor is not supported. From Visual Studio 15.8 through 16.4, add the '/experimental:preprocessor' compiler option. From Visual Studio 16.5 onwards, add the '/Zc:preprocessor' compiler option.");
    #endif // _MSVC_TRADITIONAL
    #endif // _MSC_VER

    The static_assert is a fallback for Visual Studio < 15.8, where _MSVC_TRADITIONAL isn't defined at all.

    I thought I'd share this, in case someone else runs into it. This info could also be added to the README.

    opened by martinfinke 0
  • Fix include directories in WiseEnumConfig.cmake

    Fix include directories in WiseEnumConfig.cmake

    When the project is 'installed' via CMake, the headers are copied into the directory: ${CMAKE_INSTALL_INCLUDE_DIR}/include/wise_enum, so that users get a 'stuttered' include path:

    #include <wise_enum/wise_enum.h>

    Currently (without the patch proposed here), the WiseEnumTargets.cmake file generated by the configure_package_config_file command contains the lines:

    set_target_properties(WiseEnum::wise_enum PROPERTIES

    I believe the second of those paths is probably incorrect, as it allows users to include wise_enum with either of:

    // Correct. Allowed by ${_IMPORT_PREFIX}/include
    #include <wise_enum/wise_enum.h> 
    // Incorrect. Allowed by ${_IMPORT_PREFIX}/include/wise_enum
    #include <wise_enum.h> 

    This negates the benefits of the stuttering scheme, as wise_enum.h is injected in to the global include path. The proposed patch removes the ${_IMPORT_PREFIX}/include/wise_enum path entry and ensures that callers cannot use the #include <wise_enum.h> variant.

    opened by aharrison24 0
  • 3.0.0(Oct 11, 2018)

    Release 3.0.0 adds several major features:

    1. full support for C++11
    2. a compact optional type.
    3. Support for adapting enums not defined by the wise enum macro API.
    4. Support for enums nested in classes.

    It's a breaking change because:

    1. I slightly changed the interface surrounding fixed storage enums
    2. I also slightly changed how the defaults for string and optional types work between 14 and 17.
    3. Changed the macro names to override the types slightly.

    All very minor changes, but still breaking.

    Source code(tar.gz)
    Source code(zip)
  • 2.1.0(Sep 2, 2018)

    Removed a major bug introduced in 2.0.0 where the library actually stopped working for enum classes.

    The library now partially supports enums that have multiple enumerators with the same value. This used to cause a hard failure immediately in the to_string implementation. Now, the failure only occurs if to_string is actually called.

    Source code(tar.gz)
    Source code(zip)
Nir Friedman
Nir Friedman
BokuLoader - Cobalt Strike User-Defined Reflective Loader written in Assembly & C for advanced evasion capabilities.

BokuLoader - Cobalt Strike Reflective Loader Cobalt Strike User-Defined Reflective Loader written in Assembly & C for advanced evasion capabilities. B

Bobby Cooke 833 Dec 31, 2022
KaynLdr is a Reflective Loader written in C/ASM

KaynLdr About KaynLdr is a Reflective Loader written in C / ASM. It uses direct syscalls to allocate virtual memory as RW and changes it to RX. It era

C5pider 414 Dec 28, 2022
Nameof operator for modern C++, simply obtain the name of a variable, type, function, macro, and enum

_ _ __ _____ | \ | | / _| / ____|_ _ | \| | __ _ _ __ ___ ___ ___ | |_ | | _| |

Daniil Goncharov 1.5k Jan 8, 2023
In DFS-BFS Implementation In One Program Using Switch Case I am Using an Simple And Efficient Code of DFS-BFS Implementation.

DFS-BFS Implementation-In-One-Program-Using-Switch-Case-in-C Keywords : Depth First Search(DFS), Breadth First Search(BFS) In Depth First Search(DFS),

Rudra_deep 1 Nov 17, 2021
Implementation of python itertools and builtin iteration functions for C++17

CPPItertools Range-based for loop add-ons inspired by the Python builtins and itertools library. Like itertools and the Python3 builtins, this library

Ryan Haining 1.2k Jan 7, 2023
Espressif ESP32 implementation of ANSI-ESTA E1.11 DMX-512A

This library allows for transmitting and receiving ANSI-ESTA E1.11 DMX-512A using an Espressif ESP32. It provides control and analysis of the packet configuration and allows the user to read synchronously or asynchronously from the DMX bus. This library also includes tools for data error-checking to safely process DMX commands.

null 134 Jan 9, 2023
A simple implementation of a parser and its use to calculate simple mathematical expressions

Calculator C Parser A simple implementation of a parser and its use to calculate simple mathematical expressions I haven't written a detailed descript

Romes 14 Nov 8, 2021
An implementation of a weak handle interface to a packed vector in C++

Experimental handle container in C++ Overview Following on from c-handle-container, this library builds on the same ideas but supports a dynamic numbe

Tom Hulton-Harrop 13 Nov 26, 2022
uSDR implementation based on a RP2040 Pi Pico

uSDR-pico A uSDR implementation based on a RP2040 Pi Pico. This code is experimental, intended to investigate how the HW and SDK work with an applicat

null 94 Jan 7, 2023
high performance C++20 implementation of std::variant

A minimal compile-time overhead, C++20 implementation of std::variant. Fully standard conforming with a couple of documented differences.

null 37 Nov 22, 2022
C implementation of the Monkey programming language.

Development of this interpreter continues here: dannyvankooten/pepper-lang C implementation of the Monkey programming language. Bytecode compiler and

Danny van Kooten 24 Dec 30, 2022
SleighCraft is a decoder based on ghidra's decompiler implementation.

SleighCraft is a decoder (or, linear disassembler) based on ghidra's decompiler implementation. Sleighcraft can be used in Rust or Python, with both high-level and low-level API.

PortalLab 236 Nov 6, 2022
dex-vm implementation, used to protect the classes.dex file

nmmp 基于dex-vm运行dalvik字节码从而对dex进行保护,增加反编译难度。 项目分为两部分nmm-protect是纯java项目,对dex进行转换,把dex里方法及各种数据转为c结构体,处理apk生成c项目,编译生成so,输出处理后的apk。nmmvm是一个安卓项目,包含dex-vm实现

mao 362 Jan 7, 2023
Implementation of mmap system call in xv6

NOTE: we have stopped maintaining the x86 version of xv6, and switched our efforts to the RISC-V version (https://github.com/mit-pdos/xv6-riscv.git)

Rohit Chaudhari 6 May 18, 2021
Juice the carrots from ウマ娘プリティーダービー (Umamusume Pretty Derby) - Windows implementation

Hooks the decryption function in libnative.dll of ウマ娘プリティーダービー (Umamusume Pretty Derby), to allow inspecting the packets (and provide some useful information during the game).

Huang Yue 81 Dec 16, 2022
Because why not? Pi Zero bare metal project that ends in an RTOS implementation

PiZeroRTOS Because why not? This repo starts out as a Pi Zero bare metal project and it could very well end up as a viable RTOS implementation with a

null 7 Feb 13, 2022
Jimp-native is a fast C++ re-implementation of Jimp with zero system dependencies and minimal overhead!

Jimp native Make your sever-side Jimp code run 10x faster! Jimp-native is a fast C++ re-implementation of Jimp with zero system dependencies and minim

Sjoerd 17 Oct 10, 2022
Proof-of-concept implementation for the paper "Osiris: Automated Discovery of Microarchitectural Side Channels" (USENIX Security'21)

Osiris This repository contains the implementation of the Osiris framework discussed in the research paper "Osiris: Automated Discovery of Microarchit

CISPA 41 Nov 11, 2022