a small protobuf implementation in C

Related tags

Serialization upb
Overview

μpb - a small protobuf implementation in C

Platform Build Status
macOS Build Status
ubuntu Build Status

μpb (often written 'upb') is a small protobuf implementation written in C.

upb generates a C API for creating, parsing, and serializing messages as declared in .proto files. upb is heavily arena-based: all messages always live in an arena (note: the arena can live in stack or static memory if desired). Here is a simple example:

#include "conformance/conformance.upb.h"

void foo(const char* data, size_t size) {
  upb_arena *arena;

  /* Generated message type. */
  conformance_ConformanceRequest *request;
  conformance_ConformanceResponse *response;

  arena = upb_arena_new();
  request = conformance_ConformanceRequest_parse(data, size, arena);
  response = conformance_ConformanceResponse_new(arena);

  switch (conformance_ConformanceRequest_payload_case(request)) {
    case conformance_ConformanceRequest_payload_protobuf_payload: {
      upb_strview payload = conformance_ConformanceRequest_protobuf_payload(request);
      // ...
      break;
    }

    case conformance_ConformanceRequest_payload_NOT_SET:
      fprintf(stderr, "conformance_upb: Request didn't have payload.\n");
      break;

    default: {
      static const char msg[] = "Unsupported input format.";
      conformance_ConformanceResponse_set_skipped(
          response, upb_strview_make(msg, sizeof(msg)));
      break;
    }
  }

  /* Frees all messages on the arena. */
  upb_arena_free(arena);
}

API and ABI are both subject to change! Please do not distribute as a shared library for this reason (for now at least).

Using upb in your project

Currently only Bazel is supported (CMake support is partial and incomplete but full CMake support is an eventual goal).

To use upb in your Bazel project, first add upb to your WORKSPACE file, either as a git_repository() or as a new_local_repository() with a Git Submodule. (For an example, see `examples/bazel/ in this repo).

# Add this to your WORKSPACE file.
load("@bazel_tools//tools/build_defs/repo:git.bzl", "git_repository")

git_repository(
    name = "upb",
    remote = "https://github.com/protocolbuffers/upb.git",
    commit = "d16bf99ac4658793748cda3251226059892b3b7b",
)

load("@upb//bazel:workspace_deps.bzl", "upb_deps")

upb_deps()

Then in your BUILD file you can add upb_proto_library() rules that generate code for a corresponding proto_library() rule. For example:

# Add this to your BUILD file.
load("@upb//bazel:upb_proto_library.bzl", "upb_proto_library")

proto_library(
    name = "foo_proto",
    srcs = ["foo.proto"],
)

upb_proto_library(
    name = "foo_upbproto",
    deps = [":foo_proto"],
)

cc_binary(
    name = "test_binary",
    srcs = ["test_binary.c"],
    deps = [":foo_upbproto"],
)

Then in your .c file you can #include the generated header:

#include "foo.upb.h"

/* Insert code that uses generated types. */

Old "handlers" interfaces

This library contains several semi-deprecated interfaces (see BUILD file for more info about which interfaces are deprecated). These deprecated interfaces are still used in some significant projects, such as the Ruby and PHP C bindings for protobuf in the main protobuf repo. The goal is to migrate the Ruby/PHP bindings to use the newer, simpler interfaces instead. Please do not use the old interfaces in new code.

Lua bindings

This repo has some Lua bindings for the core library. These are experimental and very incomplete. These are currently included in order to validate that the C API is suitable for wrapping. As the project matures these Lua bindings may become publicly available.

Contact

Author: Josh Haberman ([email protected], [email protected])

Comments
  • DefToProto test seg faults on big endian systems

    DefToProto test seg faults on big endian systems

    This seems to be coming from here: https://github.com/protocolbuffers/upb/blob/0cb7f72c02e899f58bc7e91b268b8077ca4b3601/upb/util/def_to_proto.c#L102-L104

    I checked that right before it seg faults:

    1. upb_fielddef_fullname(f) is google.protobuf.FileOptions.optimize_for
    2. upb_fielddef_type(f) is 5 (UPB_DESCRIPTOR_TYPE_INT32)
    3. d.int32_val is 0
    4. ev is also 0

    On my macOS build, upb_enumdef_lookupnum returns a non-zero pointer, whereas it returns 0 here.

    Digging deeper, it seems upb_inttable_lookup is returning 1 in the working case, 0 in the broken case. I have to wonder if the table implementation isn't hashing things with endian concerns.

    valgrind output shows:

    root@88265bec88fe:/build/upb# valgrind /root/.cache/bazel/_bazel_root/6bf3da2484ef4bca9a0fbec97f98a05c/execroot/upb/bazel-out/s390x-fastbuild/bin/upb/util/def_to_proto_test
    ==1540294== Memcheck, a memory error detector
    ==1540294== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
    ==1540294== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info
    ==1540294== Command: /root/.cache/bazel/_bazel_root/6bf3da2484ef4bca9a0fbec97f98a05c/execroot/upb/bazel-out/s390x-fastbuild/bin/upb/util/def_to_proto_test
    ==1540294==
    Running main() from gmock_main.cc
    [==========] Running 1 test from 1 test suite.
    [----------] Global test environment set-up.
    [----------] 1 test from DefToProto
    [ RUN      ] DefToProto.Test
    ==1540294== Invalid read of size 8
    ==1540294==    at 0x53C3B9C: upb_enumvaldef_name (in /root/.cache/bazel/_bazel_root/6bf3da2484ef4bca9a0fbec97f98a05c/execroot/upb/bazel-out/s390x-fastbuild/bin/libreflection.so)
    ==1540294==    by 0x53ACA55: default_string (in /root/.cache/bazel/_bazel_root/6bf3da2484ef4bca9a0fbec97f98a05c/execroot/upb/bazel-out/s390x-fastbuild/bin/upb/util/libdef_to_proto.so)
    ==1540294==    by 0x53ACEFB: fielddef_toproto (in /root/.cache/bazel/_bazel_root/6bf3da2484ef4bca9a0fbec97f98a05c/execroot/upb/bazel-out/s390x-fastbuild/bin/upb/util/libdef_to_proto.so)
    ==1540294==    by 0x53AD921: msgdef_toproto (in /root/.cache/bazel/_bazel_root/6bf3da2484ef4bca9a0fbec97f98a05c/execroot/upb/bazel-out/s390x-fastbuild/bin/upb/util/libdef_to_proto.so)
    ==1540294==    by 0x53AE5E3: filedef_toproto (in /root/.cache/bazel/_bazel_root/6bf3da2484ef4bca9a0fbec97f98a05c/execroot/upb/bazel-out/s390x-fastbuild/bin/upb/util/libdef_to_proto.so)
    ==1540294==    by 0x53AEBEF: upb_FileDef_ToProto (in /root/.cache/bazel/_bazel_root/6bf3da2484ef4bca9a0fbec97f98a05c/execroot/upb/bazel-out/s390x-fastbuild/bin/upb/util/libdef_to_proto.so)
    ==1540294==    by 0x112C97: AddMessageDescriptor(upb::MessageDefPtr, google::protobuf::DescriptorPool*) (in /root/.cache/bazel/_bazel_root/6bf3da2484ef4bca9a0fbec97f98a05c/execroot/upb/bazel-out/s390x-fastbuild/bin/upb/ut
    il/def_to_proto_test)
    ==1540294==    by 0x11948F: EqualsUpbProtoMatcherP2<google_protobuf_FileDescriptorProto*, upb_msgdef const* (*)(upb_symtab*)>::gmock_Impl<google_protobuf_FileDescriptorProto const* const&>::MatchAndExplain(google_protobuf
    _FileDescriptorProto const* const&, testing::MatchResultListener*) const (in /root/.cache/bazel/_bazel_root/6bf3da2484ef4bca9a0fbec97f98a05c/execroot/upb/bazel-out/s390x-fastbuild/bin/upb/util/def_to_proto_test)
    ==1540294==    by 0x117383: testing::internal::MatcherBase<google_protobuf_FileDescriptorProto const* const&>::MatchAndExplain(google_protobuf_FileDescriptorProto const* const&, testing::MatchResultListener*) const (in /r
    oot/.cache/bazel/_bazel_root/6bf3da2484ef4bca9a0fbec97f98a05c/execroot/upb/bazel-out/s390x-fastbuild/bin/upb/util/def_to_proto_test)
    ==1540294==    by 0x116897: testing::internal::MatcherBase<google_protobuf_FileDescriptorProto const* const&>::Matches(google_protobuf_FileDescriptorProto const* const&) const (in /root/.cache/bazel/_bazel_root/6bf3da2484
    ef4bca9a0fbec97f98a05c/execroot/upb/bazel-out/s390x-fastbuild/bin/upb/util/def_to_proto_test)
    ==1540294==    by 0x1156BB: testing::AssertionResult testing::internal::PredicateFormatterFromMatcher<EqualsUpbProtoMatcherP2<google_protobuf_FileDescriptorProto*, upb_msgdef const* (*)(upb_symtab*)> >::operator()<google_
    protobuf_FileDescriptorProto const*>(char const*, google_protobuf_FileDescriptorProto const* const&) const (in /root/.cache/bazel/_bazel_root/6bf3da2484ef4bca9a0fbec97f98a05c/execroot/upb/bazel-out/s390x-fastbuild/bin/upb
    /util/def_to_proto_test)
    ==1540294==    by 0x1133C3: CheckFile(upb::FileDefPtr, google_protobuf_FileDescriptorProto const*) (in /root/.cache/bazel/_bazel_root/6bf3da2484ef4bca9a0fbec97f98a05c/execroot/upb/bazel-out/s390x-fastbuild/bin/upb/util/de
    f_to_proto_test)
    ==1540294==  Address 0x10 is not stack'd, malloc'd or (recently) free'd
    ==1540294==
    ==1540294==
    ==1540294== Process terminating with default action of signal 11 (SIGSEGV): dumping core
    ==1540294==  Access not within mapped region at address 0x0
    ==1540294==    at 0x53C3B9C: upb_enumvaldef_name (in /root/.cache/bazel/_bazel_root/6bf3da2484ef4bca9a0fbec97f98a05c/execroot/upb/bazel-out/s390x-fastbuild/bin/libreflection.so)
    ==1540294==    by 0x53ACA55: default_string (in /root/.cache/bazel/_bazel_root/6bf3da2484ef4bca9a0fbec97f98a05c/execroot/upb/bazel-out/s390x-fastbuild/bin/upb/util/libdef_to_proto.so)
    ==1540294==    by 0x53ACEFB: fielddef_toproto (in /root/.cache/bazel/_bazel_root/6bf3da2484ef4bca9a0fbec97f98a05c/execroot/upb/bazel-out/s390x-fastbuild/bin/upb/util/libdef_to_proto.so)
    ==1540294==    by 0x53AD921: msgdef_toproto (in /root/.cache/bazel/_bazel_root/6bf3da2484ef4bca9a0fbec97f98a05c/execroot/upb/bazel-out/s390x-fastbuild/bin/upb/util/libdef_to_proto.so)
    ==1540294==    by 0x53AE5E3: filedef_toproto (in /root/.cache/bazel/_bazel_root/6bf3da2484ef4bca9a0fbec97f98a05c/execroot/upb/bazel-out/s390x-fastbuild/bin/upb/util/libdef_to_proto.so)
    ==1540294==    by 0x53AEBEF: upb_FileDef_ToProto (in /root/.cache/bazel/_bazel_root/6bf3da2484ef4bca9a0fbec97f98a05c/execroot/upb/bazel-out/s390x-fastbuild/bin/upb/util/libdef_to_proto.so)
    ==1540294==    by 0x112C97: AddMessageDescriptor(upb::MessageDefPtr, google::protobuf::DescriptorPool*) (in /root/.cache/bazel/_bazel_root/6bf3da2484ef4bca9a0fbec97f98a05c/execroot/upb/bazel-out/s390x-fastbuild/bin/upb/ut
    il/def_to_proto_test)
    ==1540294==    by 0x11948F: EqualsUpbProtoMatcherP2<google_protobuf_FileDescriptorProto*, upb_msgdef const* (*)(upb_symtab*)>::gmock_Impl<google_protobuf_FileDescriptorProto const* const&>::MatchAndExplain(google_protobuf
    _FileDescriptorProto const* const&, testing::MatchResultListener*) const (in /root/.cache/bazel/_bazel_root/6bf3da2484ef4bca9a0fbec97f98a05c/execroot/upb/bazel-out/s390x-fastbuild/bin/upb/util/def_to_proto_test)
    ==1540294==    by 0x117383: testing::internal::MatcherBase<google_protobuf_FileDescriptorProto const* const&>::MatchAndExplain(google_protobuf_FileDescriptorProto const* const&, testing::MatchResultListener*) const (in /r
    oot/.cache/bazel/_bazel_root/6bf3da2484ef4bca9a0fbec97f98a05c/execroot/upb/bazel-out/s390x-fastbuild/bin/upb/util/def_to_proto_test)
    ==1540294==    by 0x116897: testing::internal::MatcherBase<google_protobuf_FileDescriptorProto const* const&>::Matches(google_protobuf_FileDescriptorProto const* const&) const (in /root/.cache/bazel/_bazel_root/6bf3da2484
    ef4bca9a0fbec97f98a05c/execroot/upb/bazel-out/s390x-fastbuild/bin/upb/util/def_to_proto_test)
    ==1540294==    by 0x1156BB: testing::AssertionResult testing::internal::PredicateFormatterFromMatcher<EqualsUpbProtoMatcherP2<google_protobuf_FileDescriptorProto*, upb_msgdef const* (*)(upb_symtab*)> >::operator()<google_
    protobuf_FileDescriptorProto const*>(char const*, google_protobuf_FileDescriptorProto const* const&) const (in /root/.cache/bazel/_bazel_root/6bf3da2484ef4bca9a0fbec97f98a05c/execroot/upb/bazel-out/s390x-fastbuild/bin/upb
    /util/def_to_proto_test)
    ==1540294==    by 0x1133C3: CheckFile(upb::FileDefPtr, google_protobuf_FileDescriptorProto const*) (in /root/.cache/bazel/_bazel_root/6bf3da2484ef4bca9a0fbec97f98a05c/execroot/upb/bazel-out/s390x-fastbuild/bin/upb/util/de
    f_to_proto_test)
    ==1540294==  If you believe this happened as a result of a stack
    ==1540294==  overflow in your program's main thread (unlikely but
    ==1540294==  possible), you can try to increase the size of the
    ==1540294==  main thread stack using the --main-stacksize= flag.
    ==1540294==  The main thread stack size used in this run was 8388608.
    ==1540294==
    ==1540294== HEAP SUMMARY:
    ==1540294==     in use at exit: 248,659 bytes in 226 blocks
    ==1540294==   total heap usage: 1,735 allocs, 1,509 frees, 475,223 bytes allocated
    ==1540294==
    ==1540294== LEAK SUMMARY:
    ==1540294==    definitely lost: 0 bytes in 0 blocks
    ==1540294==    indirectly lost: 0 bytes in 0 blocks
    ==1540294==      possibly lost: 231,232 bytes in 39 blocks
    ==1540294==    still reachable: 17,427 bytes in 187 blocks
    ==1540294==         suppressed: 0 bytes in 0 blocks
    ==1540294== Rerun with --leak-check=full to see details of leaked memory
    ==1540294==
    ==1540294== For counts of detected and suppressed errors, rerun with: -v
    ==1540294== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
    
    opened by stanhu 11
  • upb is broken on Bazel CI (latest release Bazel, Linux only)

    upb is broken on Bazel CI (latest release Bazel, Linux only)

    Example breakage: https://buildkite.com/bazel/upb/builds/1235#0182f140-e79a-40af-80c7-844e49d722ad

    Apparently this is because of some fuzzing tests needing rules_python, which in turn has some error about a Python import being missing. (Our image uses Python 3.6.9.)

    opened by Wyverald 9
  • Fix big endian handling of enums

    Fix big endian handling of enums

    Previously using an enum for a field on big-endian process such as the s390x would fail to decode properly. We need to munge it in the correct byte order before decoding it.

    opened by stanhu 9
  • Split upb::Arena/upb::Allocator from upb::Environment.

    Split upb::Arena/upb::Allocator from upb::Environment.

    This will allow arenas and allocators to be used independently of environments, which will be important for an upcoming change (a message representation). Overall this design feels cleaner that the previous Environment/SeededAllocator design.

    As part of this change, moved all allocations in upb to use a global allocator instead of hard-coding malloc/free. This will allow injecting OOM faults for more robust testing.

    One place that doesn't use the global allocator is the tracked ref code. Instead of its previous approach of CHECK_OOM() after every malloc() or table insert, it simply uses an allocator that does this automatically.

    I moved Allocator/Arena/Environment into upb.h. This seems principled since these are the only types in upb whose size is directly exposed to users, since they form the basis of memory allocation strategy.

    opened by haberman 9
  • Added upb::FileDef, which represents the file defs are declared in.

    Added upb::FileDef, which represents the file defs are declared in.

    It is entirely optional: MessageDef/EnumDef can still exist on their own. But this can represent a def's file when it is desirable to do so (eg. for code generators).

    This approach will require that we change the way we handle extensions. But I think it will be a good change overall.

    Specifically, we previously handled extensions by duplicating the extended message and then adding the extension as a regular field to the duplicated message. This required also duplicating any messages that could reach the extended message.

    In the new world we will need a way of declaring and looking up extensions separately from the message being extended.

    This change also involves some notable changes to the generated code:

    • files are now called foo.upbdefs.h instead of foo.upb.h. This reflects the fact that we might possibly generate several different output files for a .proto file, and this one is just for defs.
    • we no longer generate selectors in the .h file.
    • the upbdefs.c no longer vends a SymbolTable. Now it vends the individual messages (and possibly a FileDef later). I think this will compose better once we can generate files where one generated files imports another.

    We also make the descriptor reader vend a list of FileDefs now. This is the best conceptual match for parsing a FileDescriptorSet.

    opened by haberman 9
  • Need method to reuse arena!

    Need method to reuse arena!

    I need a function to release all object create from arena, but keep the arena object not to destroyed.

    This is for avoid memory allocation/free for every small RESTful request, after response send all related object is not used but reuse the arena in next request.

    opened by calvin2021y 8
  • cmake & conan

    cmake & conan

    I have reworked the CMake support for this project, and added a conanfile.py and test_package folder for Conan support.

    • CMake

      • created cmake/Modules/ProtocGenUpb.cmake so there is a CMake function that can be used to call the upb protoc plugin and generate upb files
      • cmake/InstallHelpers.cmake, cmake/upbConfig.cmake.in, cmake/cmake_uninstall.cmake.in to generate install and uninstall targets for calling cmake --install and cmake --build . --target uninstall or ninja install/ninja uninstall etc
    • Conan

      • conanfile.py written with basic instructions for getting dependencies and building
      • test_package for testing the "consumability" of the conan/cmake build

    I am not familiar enough with Bazel to update the Bazel scripts that are used to generate the cmake files (could probably generate conan files as well), I can take a stab at it but would appreciate any help with that

    opened by AnticliMaxtic 8
  • Added upb_msg and Lua bindings for using it.

    Added upb_msg and Lua bindings for using it.

    upb_msg is a major step forward for upb. We will finally have a standard message representation, but one that interoperates with different memory management schemes (arena allocation, unique ownership, etc). This will also pave the way for representing custom options properly.

    This PR is pretty big, but it's not quite as big as it looks, because several things were shuffled around.

    In particular, the mainupb.c in the Lua bindings was split into 3: upb.c, msg.c, and def.c. So basically none of the code in def.c is actually new, even though GitHub is showing it all as added in the PR.

    Also, upb/shim/* functionality was moved into upb/msg.c.

    There is some dead code here: functionality that I implemented in upb_msg but is not tested yet (like maps, extensions, repeated string fields, etc). I didn't want to make this CL grow even more, so I decided to stop when I had parity with what the Lua implementation could do before this change. Follow-up CLs will flesh out the tests to exercise all these cases, and will fix the inevitable bugs.

    Review to @scwhittle.

    opened by haberman 8
  • Restructure tables for C89 port and smaller size.

    Restructure tables for C89 port and smaller size.

    Changes the data layout of tables slightly so that string keys are prefixed with their size, rather than the size being inline in the table itself.

    This has a few benefits:

    1. inttables shrink a bit, because there is no longer a wasted and unused size field sitting in them.
    2. This avoids the need to have a union in the table. This is important for an impending C89 port of upb, since C89 has literally no way of statically initializing a non-first union member.
    opened by haberman 8
  • Remove patter that does not glob anything

    Remove patter that does not glob anything

    This pattern does not glob anything because inside the upbc folder there is a BUILD file. Removing this allows to build upb with the flag incompatible_disallow_empty_glob

    Note: This is needed in order to build Bazel with the flag flipped.

    opened by limdor 7
  • armv7l 32-bit targets

    armv7l 32-bit targets

    I have noticed that when I compile for 32 bit targets, I get warnings about an unsafe pointer cast, i.e. -Wint-to-pointer-cast.

    The offending code: upb/msg.h line 385 upb_strview strp = (upb_strview)ent->val.val;

    More than that, I have also noticed that upb behaves very unpredictably on 32-bit targets and depending on what version of gcc I use. More of a general question but how much testing has gone into 32-bit targets and the arm family of processors? If you'd like, I'd be happy to show you more specific examples of unpredictable behavior.

    opened by csmichael-as 7
  • Add conformance test. Expect fail when serialize inf and nan for

    Add conformance test. Expect fail when serialize inf and nan for

    Add conformance test. Expect fail when serialize inf and nan for Value.number_value in json format.

    https://developers.google.com/protocol-buffers/docs/reference/google.protobuf#google.protobuf.Value where it says: attempting to serialize NaN or Infinity results in error. (We can't serialize these as string "NaN" or "Infinity" values like we do for regular fields, because they would parse as string_value, not number_value).

    opened by copybara-service[bot] 0
  • Use //:protoc_lib instead of //src/google/protobuf/compiler:code_generator.

    Use //:protoc_lib instead of //src/google/protobuf/compiler:code_generator.

    Use //:protoc_lib instead of //src/google/protobuf/compiler:code_generator.

    The latter isn’t available in released versions of Protocol Buffers, but the former is.

    opened by copybara-service[bot] 0
  • In tensorstore we have added this patch to allow upb to build proto_library

    In tensorstore we have added this patch to allow upb to build proto_library

    In tensorstore we have added this patch to allow upb to build proto_library targets such as those in @com_google_protobuf with strip_import_prefix = "src"

    opened by copybara-service[bot] 0
Owner
Protocol Buffers
A language-neutral, platform-neutral extensible mechanism for serializing structured data.
Protocol Buffers
Protocol Buffers with small code size

Nanopb - Protocol Buffers for Embedded Systems Nanopb is a small code-size Protocol Buffers implementation in ansi C. It is especially suitable for us

null 3.3k Dec 31, 2022
International obfuscated contest: Small C program to minify HTML sources and generate a minified HTML output.

HTML Minifier C International obfuscated contest: Just a small C program to minify HTML sources and generate a minified HTML output. Using $ gcc html-

Max Base 10 Oct 27, 2022
libcluon is a small and efficient, single-file and header-only library written in modern C++ to power microservices.

libcluon Linux & OSX Build (TravisCI) Win64 Build (AppVeyor) Test Coverage Coverity Analysis CII Best Practices libcluon is a small single-file, heade

Christian Berger 81 Nov 30, 2022
MessagePack implementation for C and C++ / msgpack.org[C/C++]

msgpack for C/C++ It's like JSON but smaller and faster. Overview MessagePack is an efficient binary serialization format, which lets you exchange dat

MessagePack 2.6k Dec 31, 2022
Protocol Buffers implementation in C

Overview This is protobuf-c, a C implementation of the Google Protocol Buffers data serialization format. It includes libprotobuf-c, a pure C library

null 2.2k Dec 26, 2022
An implementation of the MessagePack serialization format in C / msgpack.org[C]

CMP CMP is a C implementation of the MessagePack serialization format. It currently implements version 5 of the MessagePack Spec. CMP's goal is to be

Charlie Gunyon 290 Dec 31, 2022
Base64 Encoding implementation in C Programming Language

cb64 Base64 Encoding implementation in C Programming Language Spec: https://datatracker.ietf.org/doc/html/rfc4648#page-5 Header only So just copy cb64

Telkom DEV 1 Dec 6, 2022
static_vector implementation in terms of std::vector. No need to implement each function again and again ;)

static_vector static_vector implementation in terms of std::vector. No need to implement each function again and again ;) The usage is basically the s

Alex 6 Oct 29, 2022
A CTF fuzz powerd by protobuf.

protobuf_ctf_fuzz 一、简介 通过 protobuf + AFLplusplus 进行传统 ctf fuzz。 请参考这篇博文 来了解具体细节。 二、构建与运行 构建很简单,只需一行命令即可: 网络一定一定一定要好!!! 否则还是一条一条的粘贴 ./build.sh 中的命令运行,确

Kiprey 10 Dec 12, 2022
Protobuf for Proxyman app - Include Apple Silicon & Intel architecture

Protobuf for Proxyman macOS app Protobuf for Proxyman app - Include Apple Silicon & Intel architecture How to build Open the project on the latest Xco

Proxyman 6 Nov 29, 2021
An updated fork of sqlite_protobuf, a SQLite extension for extracting values from serialized Protobuf messages.

This fork of sqlite_protobuf fixes some issues (e.g., #15) and removes the test suite that we do not use. It also comes with proto_table, a C library

Backtrace Labs 18 Oct 19, 2022
C++11 header-only library that offers small vector, small flat map/set/multimap/multiset.

sfl library This is header-only C++11 library that offers several new containers: small_vector small_flat_set small_flat_map small_flat_multiset small

null 21 Dec 14, 2022
An implementation of Actor, Publish-Subscribe, and CSP models in one rather small C++ framework. With performance, quality, and stability proved by years in the production.

What is SObjectizer? What distinguishes SObjectizer? SObjectizer is not like TBB, taskflow or HPX Show me the code! HelloWorld example Ping-Pong examp

Stiffstream 314 Dec 26, 2022
A small implementation of regular expression matching engine in C

cregex cregex is a compact implementation of regular expression (regex) matching engine in C. Its design was inspired by Rob Pike's regex-code for the

Jim Huang 72 Dec 6, 2022
Small implementation of c++ entity component system inspired by Unity

EntityComponentSystem About This is small implementation of entity component system with C++. The API is heavily inspired by Unity ECS framework, but

Lukas Chodosevičius 2 Oct 13, 2021
A small and easy to use neural net implementation for C++. Just download and #include!

NN++ A short, self-contained, and easy-to-use neural net implementation for C++. It includes the neural net implementation and a Matrix class for basi

Gil Dekel 227 Nov 11, 2022
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
A small self-contained alternative to readline and libedit

Linenoise A minimal, zero-config, BSD licensed, readline replacement used in Redis, MongoDB, and Android. Single and multi line editing mode with the

Salvatore Sanfilippo 3.1k Jan 2, 2023
A small self-contained alternative to readline and libedit that supports UTF-8 and Windows and is BSD licensed.

Linenoise Next Generation A small, portable GNU readline replacement for Linux, Windows and MacOS which is capable of handling UTF-8 characters. Unlik

ArangoDB 340 Dec 6, 2022