A binary encoder / decoder implementation in Rust.

Overview

Bincode

CI

A compact encoder / decoder pair that uses a binary zero-fluff encoding scheme. The size of the encoded object will be the same or smaller than the size that the object takes up in memory in a running Rust program.

In addition to exposing two simple functions (one that encodes to Vec<u8>, and one that decodes from &[u8]), binary-encode exposes a Reader/Writer API that makes it work perfectly with other stream-based APIs such as Rust files, network streams, and the flate2-rs compression library.

API Documentation

Bincode in the wild

  • google/tarpc: Bincode is used to serialize and deserialize networked RPC messages.
  • servo/webrender: Bincode records webrender API calls for record/replay-style graphics debugging.
  • servo/ipc-channel: IPC-Channel uses Bincode to send structs between processes using a channel-like API.

Example

use serde::{Serialize, Deserialize};

#[derive(Serialize, Deserialize, PartialEq, Debug)]
struct Entity {
    x: f32,
    y: f32,
}

#[derive(Serialize, Deserialize, PartialEq, Debug)]
struct World(Vec<Entity>);

fn main() {
    let world = World(vec![Entity { x: 0.0, y: 4.0 }, Entity { x: 10.0, y: 20.5 }]);

    let encoded: Vec<u8> = bincode::serialize(&world).unwrap();

    // 8 bytes for the length of the vector, 4 bytes per float.
    assert_eq!(encoded.len(), 8 + 4 * 4);

    let decoded: World = bincode::deserialize(&encoded[..]).unwrap();

    assert_eq!(world, decoded);
}

Details

The encoding (and thus decoding) proceeds unsurprisingly -- primitive types are encoded according to the underlying Writer, tuples and structs are encoded by encoding their fields one-by-one, and enums are encoded by first writing out the tag representing the variant and then the contents.

However, there are some implementation details to be aware of:

  • isize/usize are encoded as i64/u64, for portability.
  • enums variants are encoded as a u32 instead of a usize. u32 is enough for all practical uses.
  • str is encoded as (u64, &[u8]), where the u64 is the number of bytes contained in the encoded string.

Specification

Bincode's format will eventually be codified into a specification, along with its configuration options and default configuration. In the meantime, here are some frequently asked questions regarding use of the crate:

Is Bincode suitable for storage?

The encoding format is stable across minor revisions, provided the same configuration is used. This should ensure that later versions can still read data produced by a previous versions of the library if no major version change has occured.

Bincode is invariant over byte-order in the default configuration (bincode::options::DefaultOptions), making an exchange between different architectures possible. It is also rather space efficient, as it stores no metadata like struct field names in the output format and writes long streams of binary data without needing any potentially size-increasing encoding.

As a result, Bincode is suitable for storing data. Be aware that it does not implement any sort of data versioning scheme or file headers, as these features are outside the scope of this crate.

Is Bincode suitable for untrusted inputs?

Bincode attempts to protect against hostile data. There is a maximum size configuration available (bincode::config::Bounded), but not enabled in the default configuration. Enabling it causes pre-allocation size to be limited to prevent against memory exhaustion attacks.

Deserializing any incoming data will not cause undefined behavior or memory issues, assuming that the deserialization code for the struct is safe itself.

Bincode can be used for untrusted inputs in the sense that it will not create a security issues in your application, provided the configuration is changed to enable a maximum size limit. Malicious inputs will fail upon deserialization.

What is Bincode's MSRV (minimum supported Rust version)?

Bincode 1.0 maintains support for rust 1.18.0. Any changes to this are considered a breaking change for semver purposes.

Comments
  • Relicense under dual MIT/Apache-2.0

    Relicense under dual MIT/Apache-2.0

    This issue was automatically generated. Feel free to close without ceremony if you do not agree with re-licensing or if it is not possible for other reasons. Respond to @cmr with any questions or concerns, or pop over to #rust-offtopic on IRC to discuss.

    You're receiving this because someone (perhaps the project maintainer) published a crates.io package with the license as "MIT" xor "Apache-2.0" and the repository field pointing here.

    TL;DR the Rust ecosystem is largely Apache-2.0. Being available under that license is good for interoperation. The MIT license as an add-on can be nice for GPLv2 projects to use your code.

    Why?

    The MIT license requires reproducing countless copies of the same copyright header with different names in the copyright field, for every MIT library in use. The Apache license does not have this drawback. However, this is not the primary motivation for me creating these issues. The Apache license also has protections from patent trolls and an explicit contribution licensing clause. However, the Apache license is incompatible with GPLv2. This is why Rust is dual-licensed as MIT/Apache (the "primary" license being Apache, MIT only for GPLv2 compat), and doing so would be wise for this project. This also makes this crate suitable for inclusion and unrestricted sharing in the Rust standard distribution and other projects using dual MIT/Apache, such as my personal ulterior motive, the Robigalia project.

    Some ask, "Does this really apply to binary redistributions? Does MIT really require reproducing the whole thing?" I'm not a lawyer, and I can't give legal advice, but some Google Android apps include open source attributions using this interpretation. Others also agree with it. But, again, the copyright notice redistribution is not the primary motivation for the dual-licensing. It's stronger protections to licensees and better interoperation with the wider Rust ecosystem.

    How?

    To do this, get explicit approval from each contributor of copyrightable work (as not all contributions qualify for copyright, due to not being a "creative work", e.g. a typo fix) and then add the following to your README:

    ## License
    
    Licensed under either of
    
     * Apache License, Version 2.0 ([LICENSE-APACHE](LICENSE-APACHE) or http://www.apache.org/licenses/LICENSE-2.0)
     * MIT license ([LICENSE-MIT](LICENSE-MIT) or http://opensource.org/licenses/MIT)
    
    at your option.
    
    ### Contribution
    
    Unless you explicitly state otherwise, any contribution intentionally submitted
    for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any
    additional terms or conditions.
    

    and in your license headers, if you have them, use the following boilerplate (based on that used in Rust):

    // Copyright 2016 bincode developers
    //
    // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or
    // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license
    // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your
    // option. This file may not be copied, modified, or distributed
    // except according to those terms.
    

    It's commonly asked whether license headers are required. I'm not comfortable making an official recommendation either way, but the Apache license recommends it in their appendix on how to use the license.

    Be sure to add the relevant LICENSE-{MIT,APACHE} files. You can copy these from the Rust repo for a plain-text version.

    And don't forget to update the license metadata in your Cargo.toml to:

    license = "MIT/Apache-2.0"
    

    I'll be going through projects which agree to be relicensed and have approval by the necessary contributors and doing this changes, so feel free to leave the heavy lifting to me!

    Contributor checkoff

    To agree to relicensing, comment with :

    I license past and future contributions under the dual MIT/Apache-2.0 license, allowing licensees to chose either at their option.
    

    Or, if you're a contributor, you can check the box in this repo next to your name. My scripts will pick this exact phrase up and check your checkbox, but I'll come through and manually review this issue later as well.

    • [x] @TyOverby
    • [x] @bitonic
    • [x] @erickt
    • [x] @crhino
    • [x] @jmesmon
    • [x] @mikedilger
    • [x] @tedsta
    • [x] @nyx
    • [x] @csherratt
    • [x] @badboy
    • [x] @jeremyjh
    • [x] @reem
    • [x] @mohtar
    • [x] @SimonSapin
    opened by emberian 30
  • Are the size limits necessary?

    Are the size limits necessary?

    I was about to update the library to the latest version of rustc-serialize (now with associated types), and I noticed the last commit.

    Is it necessary, considering that the size limit can be easily enforce through the writer -- e.g. with a BufWriter?

    opened by bitonic 22
  • Unable to use bincode when serializing without macros. Get SyntaxError.

    Unable to use bincode when serializing without macros. Get SyntaxError.

    I'm not sure if this is the right place for this, but

    I am unable to use bincode to serialize and deserialize structs where the serialize and deserialize traits are implemented instead of derived. For example, I copied the Point struct, and the serialize and deserialize implementations used in the "Serliazation without macros" section of the readme here, https://github.com/serde-rs/serde#serialization-without-macros and attempted to use bincode to serialize and deserialize a Point variable. I was unable to do so and got this error

    thread '

    ' panicked at 'called Result::unwrap() on an Err value: SyntaxError', ../src/libcore/result.rs:738 Process didn't exit successfully: target/debug/tcpLocal (exit code: 101)

    If I instead derive the serialize and deserialize traits, I can serialize and deserialize the Point variable fine. Using the copied implementations of serialize and deserialize, I can serialize and deserialize from JSON just fine.

    Is this expected? Did I miss something where only serializing with macros is supported in bincode?

    • Thanks
    opened by rigdent 20
  • Add null terminated string option

    Add null terminated string option

    Hello!

    I am working with a protocol that is 99% compatible with the data structures I already use, bar one thing: it uses c-style strings. I know that bincode is technically its own protocol but if we were to support different string formats it would save me 100 lines of custom code...

    ...So here's 140 lines of custom code that adds a flag similar to the varint flag that allows the user to select between 'vec-style' encoding and 'c-style' encoding. I have marked it as a draft because I wanted to make sure you were open to merging something like this before I finished it.

    Thanks! :christmas_tree:

    opened by arlyon 15
  • Please don't break current Rust versions because of concerns about outdated Rust versions

    Please don't break current Rust versions because of concerns about outdated Rust versions

    I see that you've blocked updates of byteorder due to concern for Rust 1.18 compatibility (#381, #380). However, in doing so, you're causing problems for all Rust versions:

    error: failed to select a version for `byteorder`.
        ... required by package `bincode v1.3.2`
    

    I know your change isn't technically a semver-breaking, but because of the way Cargo resolves dependencies, it is breaking builds (I have byteorder 1.3.2 elsewhere in the dependency tree, and cargo update can't deal with it).

    Paradoxically, in a good-faith attempt to avoid breaking anyone, you've caused more breakage.

    Please don't cause pain for all Rust users out of concern for users who use an outdated Rust version.

    opened by kornelski 14
  • no_std support?

    no_std support?

    I didn't see no_std support in the documentation / cargo.toml / issues so I thought I would open one. This library seems perfect for no_std serialization in microcontrollers. What are the biggest barriers to supporting no_std? Would you welcome a PR that did so?

    Thanks!

    opened by vitiral 14
  • Make `i128` support automatic

    Make `i128` support automatic

    To revisit #236, it would be more convenient for users if i128 support was enabled automatically on compatible compilers. We already argued in July that this was the best option for Rand.

    The linked PR shows how this can be achieved without any breakage (except for old nightlies, which are generally not possible to ensure support for anyway).

    opened by dhardy 13
  • bincode doesn't generate stable serializations of HashMap

    bincode doesn't generate stable serializations of HashMap

    When serializing a struct with a HashMap it's easy to end up with two values that are equal to each other but serialize to different output. An example that fails sometimes:

    #[macro_use] extern crate serde_derive;
    extern crate bincode;
    
    use std::collections::HashMap;
    
    #[derive(Debug, PartialEq, Serialize, Deserialize)]
    struct MyStruct {
        map: HashMap<u64, u64>,
    }
    
    fn main() {
        let mut map = HashMap::new();
        map.insert(0, 0);
        map.insert(1, 1);
    
        let s1 = MyStruct{map,};
        let e1: Vec<u8> = bincode::serialize(&s1).unwrap();
        let s2: MyStruct = bincode::deserialize(&e1).unwrap();
        let e2: Vec<u8> = bincode::serialize(&s2).unwrap();
        
        println!("struct1 is {:?}", s1);
        println!("struct2 is {:?}", s2);
    
        assert_eq!(s1, s2);
        assert_eq!(e1, e2);
    }
    

    This is most likely because rust is seeding the hash with different values on different runs and bincode serializes in hash order and not key order. This makes it hard to use bincode to hash a struct for deduplication/content addressing purposes.

    opened by pedrocr 13
  • Set is_human_readable to false

    Set is_human_readable to false

    I have not released this yet but I will in the next few days. https://github.com/serde-rs/serde/pull/1044

    trait Serializer {
        /* ... */
    
        fn is_human_readable(&self) -> bool { true }
    }
    
    trait Deserializer<'de> {
        /* ... */
    
        fn is_human_readable(&self) -> bool { true }
    }
    

    Bincode should override these to false to get more compact representation for types like IpAddr and Datetime.

    opened by dtolnay 13
  • Add a feature flag to disable extra debug info

    Add a feature flag to disable extra debug info

    The issue is in bincode_derive crate, where we are adding extra debug info that are leaking enum names in the final binary (which imply less optimization with a bigger binary size, and internal structure leak). I think we should use a proper feature flag to disable this. I'm working on a pull request to address that issue.

    It seems there is only one leak in the code in this part of the code. I agree this debug line can be important, but should be optional for release build if required. A feature flag could be used to address that situation, and maybe it is useful for other cases like in #594.

    opened by capatoles 12
  • proposal: Add variant encode for array length

    proposal: Add variant encode for array length

    Background

    Collections said: The length value is based on your IntEncoding.

    But in fact, array length only supports write_fixed_array_length and skip_fixed_array_length.

    let arr: [u8; 5] = [10, 20, 30, 40, 50];
    let encoded = bincode::encode_to_vec(arr, bincode::config::legacy()).unwrap();
    assert_eq!(encoded.as_slice(), &[
        5, 0, 0, 0, 0, 0, 0, 0, // The length, as a u64
        10, 20, 30, 40, 50, // the bytes
    ]);
    
    let encoded = bincode::encode_to_vec(arr, bincode::config::legacy().skip_fixed_array_length()).unwrap();
    assert_eq!(encoded.as_slice(), &[
        // no length
        10, 20, 30, 40, 50, // the bytes
    ]);
    

    Proposal

    We can support variant encodes for array length, which can make our array smaller, especially for arrays smaller than 256 (The cases happened in databend which will operate many small slices)

    let arr: [u8; 5] = [10, 20, 30, 40, 50];
    let encoded = bincode::encode_to_vec(arr, bincode::config::legacy().write_variant_array_length()).unwrap();
    assert_eq!(encoded.as_slice(), &[
        5, // The length, as a single byte
        10, 20, 30, 40, 50, // the bytes
    ]);
    

    Reference

    Add a new const bool in trait InternalArrayLengthConfig:

    pub trait InternalArrayLengthConfig {
        const SKIP_FIXED_ARRAY_LENGTH: bool;
        const WIRTE_VARIANT_ARRAY_LENGTH: bool;
    }
    

    Implement a config struct:

    #[doc(hidden)]
    #[derive(Copy, Clone)]
    pub struct WriteVariantArrayLength {}
    
    impl InternalArrayLengthConfig for WriteVariantArrayLength {
        const SKIP_FIXED_ARRAY_LENGTH: bool = false;
        const WIRTE_VARIANT_ARRAY_LENGTH: bool = true;
    }
    

    Alternative

    If API break is allowed, we can make InternalArrayLengthConfig refer to an enum:

    enum InternalArrayLengthOption {
        SKIP_FIXED_ARRAY_LENGTH,
        WIRTE_VARIANT_ARRAY_LENGTH,
        WIRTE_FIXED_ARRAY_LENGTH,
    }
    
    pub trait InternalArrayLengthConfig {
        const SKIP_FIXED_ARRAY_LENGTH: InternalArrayLengthOption;
    }
    

    Other contexts

    We have implemented the same feature on bincode v1 on our fork: https://github.com/datafuse-extras/bincode

    opened by Xuanwo 12
  • Derive macros fail with new

    Derive macros fail with new "explicit discriminants on enums with fields"

    Rust 1.66 was just released, along with Explicit discriminants on enums with fields. The given example does not compile when adding bincode (2.0.0-rc.2) derive macros to the enum:

    $ cargo -V
    # cargo 1.66.0 (d65d197ad 2022-11-15)
    
    #[derive(Decode, Encode)]
    #[repr(u8)]
    enum Foo {
        A(u8),
        B(i8),
        C(bool) = 42,
    }
    
    # error: Invalid rust syntax, expected ident, got Some(Punct { ch: '=', spacing: Alone, span: #0 bytes(334..335) })
    
    enhancement not-stale bincode-2 
    opened by timwie 1
  • Exposing config to implement custom Encode/Decode

    Exposing config to implement custom Encode/Decode

    I am trying to create custom Encode/Decode implementations for types in other crates that I'd like to use. However, I cant access the configuration as done on the impls.rs file of the encoder. How can I access the config (endianess, fixed/varint, etc) to write the data from the external type according to the config of the encoder/decoder?

    enhancement not-stale bincode-2 
    opened by Code0x2 4
  • Secure by design `deserialize_from()`

    Secure by design `deserialize_from()`

    We just realized after blissfully having used deserialize_from() for quite a while that it is potentially very dangerous when not used in conjunction with with_limit(). And unless you carefully read through the Bincode readme, you won't be aware of the existence of this issue.

    I've spent some time looking into why this is as unsafe as it is and realized that it's due to the fact that the std::io::Read trait provides zero information about the remaining number of bytes. So all Bincode can do is blindly allocate however many bytes the u64 value it just decoded tells it to. Enforcing a default limit is similarly problematic, as it may both break some clients that are not aware of it and still result in unsafely large allocations for other clients.

    But then it dawned on me that one could modify the Bincode API so that it requires an explicit limit whenever using deserialize_from(). E.g. by replacing deserialize_from(reader) with deserialize_from(reader, limit). This would immediately make it obvious to Bincode users that they need to make a trade-off between convenience and safety.

    Those that only ever deal with trusted inputs can always go with usize::MAX. And those that (like us) are actually dealing with a reader on top of a slice, can simply get rid of the reader (and the need to pick an explicit limit) and use deserialize() instead.

    Just an idea, but it feels to me like a net improvement over the status quo.

    enhancement bincode-2 documentation 
    opened by alin-at-dfinity 5
  • v2 release candidate initiative to include stateful decode impls akin to serde's DeserializeSeed?

    v2 release candidate initiative to include stateful decode impls akin to serde's DeserializeSeed?

    With the transition to the bincode specific encode and decode traits in the v2 release candidate, it appears there is currently no mechanism available for stateful deserialization comparable to Serde's DeserializeSeed trait.

    See: https://github.com/serde-rs/serde/blob/f52d134c14f6904010d0a59107987b050b36b811/serde/src/de/mod.rs#L770

    The following trait definitions could be included to provide this functionality.

    pub trait DecodeSeed: Sized {
        type Value;
    
        fn decode_seed<D: Decoder>(self, decoder: &mut D) -> Result<Self::Value, DecodeError>;
    }
    
    pub trait BorrowDecodeSeed<'de>: Sized {
        type Value;
    
        fn borrow_decode_seed<D: BorrowDecoder<'de>>(self, decoder: &mut D) -> Result<Self::Value, DecodeError>;
    }
    

    For example, utilizing the DecodeSeed trait defined above, the SequenceSeed struct could be defined below:

    struct SequenceSeed<'a>(&'a mut Vec<f64>);
    
    impl<'a> DecodeSeed for SequenceSeed<'a> {
        type Value = u64;
    
        #[inline]
        fn decode_seed<D: bincode::de::Decoder>(self, decoder: &mut D) -> Result<Self::Value, bincode::error::DecodeError> {
            let size: u64 = bincode::Decode::decode(decoder)?;
    
            for _ in 0..size {
                let element = bincode::Decode::decode(decoder)?;
                self.0.push(element)
            }
    
            Ok(size)
        }
    }
    

    Utilizing SequenceSeed, we can append each decoded element to a pre-allocated vector.

    // Encode
    let values = vec![34.5, 345.3, 40.3, 100.55, 60.5];
    let buffer = bincode::encode_to_vec(&values, config::standard()).expect("Failed to encode");
    
    // Construct decoder
    let slice_reader = bincode::de::read::SliceReader::new(&buffer[..]);
    let mut decoder = bincode::de::DecoderImpl::new(slice_reader, config::standard());
    
    // Construct SequenceSeed utilizing pre-allocated vector
    let mut seq = Vec::with_capacity(5);
    let seed = SequenceSeed(&mut seq);
    
    // Decode using SequenceSeed's DecodeSeed implementation
    let len = seed.decode_seed(&mut decoder).expect("Failed to decode");
    
    println!("{len}");  // 5
    println!("{seq:?}") // [34.5, 345.3, 40.3, 100.55, 60.5]
    

    I feel this functionality provides many opportunities for optimizations and would be a useful addition.

    opened by FinFighter 6
  • `Encode` derive macro breaks when inside macro

    `Encode` derive macro breaks when inside macro

    error[E0425]: cannot find value `field_0` in this scope
      --> bug/src/lib.rs:4:29
       |
    1  | / macro_rules! dv {
    2  | |     ($($t:item),+) => {
    3  | |         $(
    4  | |             #[derive(Clone, bincode::Encode, bincode::Decode)]
       | |                             ^^^^^^^^^^^^^^^
       | |                             |
       | |                             not found in this scope
       | |                             in this derive macro expansion (#2)
    ...  |
    7  | |     }
    8  | | }
       | |_- in this expansion of `dv!` (#1)
    ...
    11 | / dv! {
    12 | |     pub struct Foo {},
    13 | |     pub enum Bar {
    14 | |         A(Foo),
    15 | |         B,
    16 | |     }
    17 | | }
       | |_- in this macro invocation (#1)
       |
      ::: /home/lxb/.cargo/registry/src/github.com-1ecc6299db9ec823/bincode_derive-2.0.0-rc.1/src/lib.rs:9:1
       |
    9  |   pub fn derive_encode(input: proc_macro::TokenStream) -> proc_macro::TokenStream {
       |   ------------------------------------------------------------------------------- in this expansion of `#[derive(bincode::Encode)]` (#2)
    
    macro_rules! dv {
        ($($t:item),+) => {
            $(
                #[derive(Clone, bincode::Encode, bincode::Decode)]
                $t
            )+
        }
    }
    
    // Doesn't compile
    dv! {
        pub struct Foo {},
        pub enum Bar {
            A(Foo),
            B,
        }
    }
    
    // Compiles
    #[derive(Clone, bincode::Encode, bincode::Decode)]
    pub struct Foo2 {}
    #[derive(Clone, bincode::Encode, bincode::Decode)]
    pub enum Bar2 {
        A(Foo2),
        B,
    }
    
    [package]
    name = "bug"
    version = "0.1.0"
    edition = "2021"
    
    [dependencies]
    bincode = { version = "2.0.0-rc.1", default-features = false, features = ["derive"] }
    

    This doesn't seem to happen with Decode

    not-stale bincode-2 bug(fix) 
    opened by AlexApps99 1
  • Specify MSRV by using `rust-version` in `Cargo.toml`

    Specify MSRV by using `rust-version` in `Cargo.toml`

    Currently, the readme states:

    Bincode 2.0 is still in development and does not yet have a targeted MSRV. Once 2.0 is fully released the MSRV will be locked. After this point any changes to the MSRV are considered a breaking change for semver purposes.

    I would suggest to specify the MSRV in Cargo.toml by using rust-version field as soon as a MSRV is selected so tools like cargo and clippy work better with the code.

    enhancement not-stale bincode-2 
    opened by hellow554 0
Releases(v2.0.0-rc.2)
  • v2.0.0-rc.2(Oct 4, 2022)

    What's Changed

    • Add zoxide under Bincode in the Wild by @ajeetdsouza in https://github.com/bincode-org/bincode/pull/525
    • Made the Cow Encode constraints more permissive by @VictorKoenders in https://github.com/bincode-org/bincode/pull/524
    • Added additional to the UnexpectedEnd decode error by @VictorKoenders in https://github.com/bincode-org/bincode/pull/522
    • Allow encoding/decoding of HashMap and HashSet with custom hash algorithms by @bronsonp in https://github.com/bincode-org/bincode/pull/529
    • Added std::error::Error::source by @VictorKoenders in https://github.com/bincode-org/bincode/pull/530
    • Added cross platform tests workflow by @VictorKoenders in https://github.com/bincode-org/bincode/pull/534
    • Fix riscv32 atomics and fix tests on 32-bit platforms by @xobs in https://github.com/bincode-org/bincode/pull/533
    • Fix cross platform tests by @VictorKoenders in https://github.com/bincode-org/bincode/pull/540
    • Switched to weak dependencies by @VictorKoenders in https://github.com/bincode-org/bincode/pull/538
    • Fix tuple struct encoding in serde by @ZoeyR in https://github.com/bincode-org/bincode/pull/549
    • Rewrite: seperated Decode and BorrowDecode by @VictorKoenders in https://github.com/bincode-org/bincode/pull/526
    • Add impl Encode for [T], where T: Encode by @cronokirby in https://github.com/bincode-org/bincode/pull/542
    • Add impls for Rc<[T]> and Arc<[T]> by @maciejhirsz in https://github.com/bincode-org/bincode/pull/552
    • Shrink DecodeError from 48 to 32 bytes on 64-bit arch by @maciejhirsz in https://github.com/bincode-org/bincode/pull/553
    • Added windows and macos runner by @VictorKoenders in https://github.com/bincode-org/bincode/pull/554
    • Implement Decode for Box<str> by @SabrinaJewson in https://github.com/bincode-org/bincode/pull/562
    • Fixed clippy warning and updated DecodeError by @VictorKoenders in https://github.com/bincode-org/bincode/pull/574
    • Updated test dependencies: uuid and glam by @VictorKoenders in https://github.com/bincode-org/bincode/pull/576
    • Made peek_read take &mut self by @VictorKoenders in https://github.com/bincode-org/bincode/pull/572
    • Prefixed the E and D generic argument in bincode-derive by @VictorKoenders in https://github.com/bincode-org/bincode/pull/573
    • Implement Default for Configuration by @VictorKoenders in https://github.com/bincode-org/bincode/pull/575
    • Document what the usizes are for (#546) by @gimbles in https://github.com/bincode-org/bincode/pull/577
    • Clarify config::legacy() doc to match config::standard() by @trevyn in https://github.com/bincode-org/bincode/pull/580
    • Implement Encode for tuples with up-to 16 elements. by @gz in https://github.com/bincode-org/bincode/pull/583
    • Document configuration generics by @trevyn in https://github.com/bincode-org/bincode/pull/581
    • Extended BorrowDecode for HashMap to support custom hashers by @Speedy37 in https://github.com/bincode-org/bincode/pull/585
    • Allow decoding with custom DeserializeSeed by @MrGVSV in https://github.com/bincode-org/bincode/pull/586
    • Added [serde(tag)] to the list of tags that are known to give issues by @VictorKoenders in https://github.com/bincode-org/bincode/pull/584
    • Release 2.0.0-rc.2 by @VictorKoenders in https://github.com/bincode-org/bincode/pull/588

    New Contributors

    • @ajeetdsouza made their first contribution in https://github.com/bincode-org/bincode/pull/525
    • @bronsonp made their first contribution in https://github.com/bincode-org/bincode/pull/529
    • @xobs made their first contribution in https://github.com/bincode-org/bincode/pull/533
    • @cronokirby made their first contribution in https://github.com/bincode-org/bincode/pull/542
    • @maciejhirsz made their first contribution in https://github.com/bincode-org/bincode/pull/552
    • @SabrinaJewson made their first contribution in https://github.com/bincode-org/bincode/pull/562
    • @gimbles made their first contribution in https://github.com/bincode-org/bincode/pull/577
    • @trevyn made their first contribution in https://github.com/bincode-org/bincode/pull/580
    • @gz made their first contribution in https://github.com/bincode-org/bincode/pull/583
    • @Speedy37 made their first contribution in https://github.com/bincode-org/bincode/pull/585
    • @MrGVSV made their first contribution in https://github.com/bincode-org/bincode/pull/586

    Full Changelog: https://github.com/bincode-org/bincode/compare/v2.0.0-rc.1...v2.0.0-rc.2

    Source code(tar.gz)
    Source code(zip)
  • v2.0.0-rc.1(Mar 4, 2022)

    What's Changed

    • Reference implementations for Reader and Writer by @BRA1L0R in https://github.com/bincode-org/bincode/pull/507
    • Made config::standard() implement .write_fixed_array_header() by default by @VictorKoenders in https://github.com/bincode-org/bincode/pull/509
    • Added HashSet by @VictorKoenders in https://github.com/bincode-org/bincode/pull/516
    • Made the compat fuzzer ignore any LimitExceeded error by @VictorKoenders in https://github.com/bincode-org/bincode/pull/515
    • Release 2.0.0-rc.1 by @VictorKoenders in https://github.com/bincode-org/bincode/pull/510

    New Contributors

    • @BRA1L0R made their first contribution in https://github.com/bincode-org/bincode/pull/507

    Full Changelog: https://github.com/bincode-org/bincode/compare/v2.0.0-beta.3...v2.0.0-rc.1

    Source code(tar.gz)
    Source code(zip)
  • v2.0.0-beta.3(Feb 16, 2022)

    What's Changed

    • Added a table to the documentation to pick which functions to use by @VictorKoenders in https://github.com/bincode-org/bincode/pull/490
    • Fix a bunch of typos by @poljar in https://github.com/bincode-org/bincode/pull/492
    • Return an error if a decoded slice length doesn't fit into usize by @poljar in https://github.com/bincode-org/bincode/pull/491
    • Updated to virtue 0.0.6, added #[bincode(crate = other)] attribute by @VictorKoenders in https://github.com/bincode-org/bincode/pull/494
    • Bumped dependency of virtue to 0.0.7 by @VictorKoenders in https://github.com/bincode-org/bincode/pull/495
    • Bincode 1 compatibility framework by @VictorKoenders in https://github.com/bincode-org/bincode/pull/489
    • Added documentation on how to add compatibility tests by @VictorKoenders in https://github.com/bincode-org/bincode/pull/497
    • Made the compatibility check also include bincode 2 serde, and added comments by @VictorKoenders in https://github.com/bincode-org/bincode/pull/501
    • Fix CString compatibility with bincode v1 by @ZoeyR in https://github.com/bincode-org/bincode/pull/502
    • Fuzz for compatibility with bincode v1 by @5225225 in https://github.com/bincode-org/bincode/pull/498
    • Fix/issue 500 by @VictorKoenders in https://github.com/bincode-org/bincode/pull/503
    • Add Membership test by @ppamorim in https://github.com/bincode-org/bincode/pull/500
    • Release v2.0.0-beta.3 by @VictorKoenders in https://github.com/bincode-org/bincode/pull/505

    New Contributors

    • @poljar made their first contribution in https://github.com/bincode-org/bincode/pull/492
    • @ppamorim made their first contribution in https://github.com/bincode-org/bincode/pull/500

    Full Changelog: https://github.com/bincode-org/bincode/compare/v2.0.0-beta.2...v2.0.0-beta.3

    Source code(tar.gz)
    Source code(zip)
  • v2.0.0-beta.2(Jan 23, 2022)

    What's Changed

    • Run code coverage on all features by @ZoeyR in https://github.com/bincode-org/bincode/pull/485
    • Added #[serde(untagged)] to the documentation of attributes that don't work by @VictorKoenders in https://github.com/bincode-org/bincode/pull/486
    • Fixed an error in bincode derive where it would implement the wrong trait if a generic parameter is present by @VictorKoenders in https://github.com/bincode-org/bincode/pull/487
    • Release v2.0.0-beta.2 by @VictorKoenders in https://github.com/bincode-org/bincode/pull/488

    Full Changelog: https://github.com/bincode-org/bincode/compare/v2.0.0-beta.1...v2.0.0-beta.2

    Source code(tar.gz)
    Source code(zip)
  • v2.0.0-beta.1(Jan 19, 2022)

    What's Changed

    • Fix overflow error when deserializing invalid Duration by @5225225 in https://github.com/bincode-org/bincode/pull/465
    • Fix panic with invalid system time by @5225225 in https://github.com/bincode-org/bincode/pull/469
    • Add fuzzing harness, try to decode into various types by @5225225 in https://github.com/bincode-org/bincode/pull/468
    • Switched Decode and BorrowDecode to take &mut D by @VictorKoenders in https://github.com/bincode-org/bincode/pull/470
    • Switch Encode to take &mut E by @ZoeyR in https://github.com/bincode-org/bincode/pull/471
    • Implemented the newly stabilized CString::from_vec_with_nul method by @VictorKoenders in https://github.com/bincode-org/bincode/pull/473
    • Made SerdeDecoder attempt to allocate memory before complaining by @VictorKoenders in https://github.com/bincode-org/bincode/pull/475
    • Update documentation by @VictorKoenders in https://github.com/bincode-org/bincode/pull/480
    • Moved Configuration::standard() and ::legacy() to the config module by @VictorKoenders in https://github.com/bincode-org/bincode/pull/481
    • Feature/improve serde by @VictorKoenders in https://github.com/bincode-org/bincode/pull/477
    • made the serde functions consistent with the base bincode functions by @VictorKoenders in https://github.com/bincode-org/bincode/pull/483
    • Migration guide by @VictorKoenders in https://github.com/bincode-org/bincode/pull/482
    • Release v2.0.0-beta.1 by @VictorKoenders in https://github.com/bincode-org/bincode/pull/484

    New Contributors

    • @5225225 made their first contribution in https://github.com/bincode-org/bincode/pull/465

    Full Changelog: https://github.com/bincode-org/bincode/compare/v2.0.0-beta.0...v2.0.0-beta.1

    Source code(tar.gz)
    Source code(zip)
  • v2.0.0-beta.0(Jan 8, 2022)

    What's Changed

    • feat: Make Configuration functions const by @Popog in https://github.com/bincode-org/bincode/pull/456
    • Fix failed varint bench by @ygf11 in https://github.com/bincode-org/bincode/pull/457
    • Updated readme, added a paragraph on why we don't support #[repr(u8)] by @VictorKoenders in https://github.com/bincode-org/bincode/pull/461
    • Bump virtue 0.0.4 by @VictorKoenders in https://github.com/bincode-org/bincode/pull/463
    • Fixed derive impl on an empty enum by @VictorKoenders in https://github.com/bincode-org/bincode/pull/462

    New Contributors

    • @Popog made their first contribution in https://github.com/bincode-org/bincode/pull/456
    • @ygf11 made their first contribution in https://github.com/bincode-org/bincode/pull/457

    Full Changelog: https://github.com/bincode-org/bincode/compare/V2.0.0-alpha.2...v2.0.0-beta.0

    Source code(tar.gz)
    Source code(zip)
  • V2.0.0-alpha.2(Dec 14, 2021)

    Breaking:

    • All decode_from_slice functions now also return the number of bytes read #445
    • Bincode-derive now auto-implements T: Encode when implementing #[derive(Encode)] (same for Decode/DecodeBorrowed)
      • See https://github.com/bincode-org/bincode/pull/451 for more information

    Config integer limit

    Bincode now supports size limits again. Size limits can be configured as followed:

    let config = Configuration::standard() // or ::legacy()
        .with_limit::<10000>();
    
    • Documentation: https://docs.rs/bincode/2.0.0-alpha.2/bincode/config/struct.Configuration.html#method.with_limit
    • Pull request: https://github.com/bincode-org/bincode/pull/439

    Other changes:

    • Added Decode/Encode for HashMap<K, V>: https://github.com/bincode-org/bincode/pull/438
    • Added test case for a borrowed str: https://github.com/bincode-org/bincode/pull/441
    • Fixed clippy warnings: https://github.com/bincode-org/bincode/pull/447
    • Impl BorrowDecode for Option<&[u8]> and Option<&str>: https://github.com/bincode-org/bincode/pull/446
    • Extract virtue: https://github.com/bincode-org/bincode/pull/443
    • Made the CI also check the benchmarks, fixed compile issue in benchmarks: https://github.com/bincode-org/bincode/pull/449
    • Made the derive macros automatically implement the required traits on generic arguments: https://github.com/bincode-org/bincode/pull/454

    Full Changelog: https://github.com/bincode-org/bincode/compare/v2.0.0-alpha.1...V2.0.0-alpha.2

    Source code(tar.gz)
    Source code(zip)
  • v2.0.0-alpha.1(Nov 9, 2021)

    • Support for serde through Compat and BorrowCompat modules and serde-specific encode/decode functions.
    • Split bincode_derive's Decode and BorrowDecode
    • Fixed constraint on implementation for Cow<T>
    • Several minor bugfixes
    Source code(tar.gz)
    Source code(zip)
  • v2.0.0-alpha.0(Oct 25, 2021)

    Complete rewrite of bincode. Refer to the documentation on how to use the current version. Migration guides and detailed changes coming later.

    Source code(tar.gz)
    Source code(zip)
  • v1.3.3(Apr 10, 2021)

  • v1.3.2(Feb 24, 2021)

  • v1.3.1(Feb 24, 2021)

  • v1.3.0(Feb 24, 2021)

    • Removed UB in IoReader
    • Exposed serializer types
    • Added varint encoding
    • Modernize config system
    • Added option to reject trailing bytes during slice decoding
    Source code(tar.gz)
    Source code(zip)
  • v1.2.1(Dec 10, 2019)

    • Add impl Clone for bincode::Config (#282, thanks @jean-airoldie)
    • Fix Emscripten build failures associated with i128 support (#281, thanks @jstarry)
    Source code(tar.gz)
    Source code(zip)
  • v1.1.4(May 15, 2019)

  • v1.1.3(Apr 8, 2019)

  • v1.1.2(Feb 16, 2019)

  • v1.0.0-alpha7(Feb 16, 2019)

  • v1.0.0-alpha6(Feb 16, 2019)

  • v1.0.0-alpha4(Feb 16, 2019)

Owner
Bincode
Bincode
An impish, cross-platform binary parsing crate, written in Rust

libgoblin Documentation https://docs.rs/goblin/ changelog Usage Goblin requires rustc 1.40.0. Add to your Cargo.toml [dependencies] goblin = "0.3" Fea

null 892 Dec 29, 2022
Implementation of the Jubjub elliptic curve group

jubjub This is a pure Rust implementation of the Jubjub elliptic curve group and its associated fields. This implementation has not been reviewed or a

Zero-knowledge Cryptography in Rust 74 Dec 12, 2022
Safe and ergonomic Rust-Mach bindings.

mach-rs This project aims to provide safe and ergonomic bindings to Mach APIs for the Rust programming language. License Copyright (c) 2021 Umang Ragh

Umang Raghuvanshi 7 Nov 21, 2022
rkyv (archive) is a zero-copy deserialization framework for Rust

rkyv (archive) is a zero-copy deserialization framework for Rust Resources Learning Materials The rkyv book covers the motivation, architecture, and m

rkyv 1.6k Jan 5, 2023
A binary encoder / decoder implementation in Rust.

Bincode A compact encoder / decoder pair that uses a binary zero-fluff encoding scheme. The size of the encoded object will be the same or smaller tha

Bincode 1.9k Dec 29, 2022
A Rust encoder/decoder for Dominic Szablewski's QOI format for fast, lossless image compression.

QOI - The “Quite OK Image” format This is a Rust encoder and decoder for Dominic Szablewski's QOI format for fast, lossless image compression. See the

Chevy Ray Johnston 62 Nov 29, 2022
A basic rust QOI decoder/encoder

libqoi A basic rust QOI decoder/encoder. Why QOI QOI is a lossless image format with a one page specification. It can achieve better compression than

null 2 May 21, 2022
Free Rust-only Xbox ADPCM encoder and decoder

XbadPCM Safe (and optionally no-std) Rust crate for encoding and decoding Xbox ADPCM blocks. Decoding example Here is example code for decoding stereo

Snowy 5 Nov 20, 2022
mico (minimalistic config file format) encoder and decoder

mico This library implements a parser and emitter for mico (minimalistic config file format). Format example: Name: mico Description: minimalistic con

null 1 Jan 30, 2022
Entropy Encoding notebook. Simple implementations of the "tANS" encoder/decoder.

EntropyEncoding Experiments This repository contains my Entropy Encoding notebook. Entropy encoding is an efficient lossless data compression scheme.

Nadav Rotem 4 Dec 21, 2022
Fast encoder/decoder for the lossless DTM 16 bit image format

DTM Image Format Fast encoder/decoder for the DTM image format. The DTM image format is a 16-bit lossless image format supporting one to four channels

Kurt Kühnert 4 Oct 15, 2022
decoder (and encoder) for quaternions sent from a joycon. Based heavily on reverse engineering done by hexkyz.

joycon-quat decoder (and encoder) for quaternions sent from a joycon. Based heavily on reverse engineering done by hexkyz. for those who want to use i

Kitlith 3 Feb 28, 2024
banzai: pure rust bzip2 encoder

banzai banzai is a bzip2 encoder with linear-time complexity, written entirely in safe Rust. It is currently alpha software, which means that it is no

Jack Byrne 27 Oct 24, 2022
BitTorrent peer ID registry/parser/(soon) encoder for Rust

BitTorrent peer ID registry/parser/(soon) encoder By convention, BitTorrent clients identify themselves and their versions in peer IDs they send to tr

TORRENTDYNE 3 Oct 16, 2023
Rust port of ffmpeg's native AAC encoder

raash ?? An attempt at RIIR-ing the native AAC encoder from ffmpeg. First, I used c2rust to translate all relevant C code into Rust, and I'm in the pr

Yotam Ofek 6 Dec 1, 2023
The fastest and safest AV1 encoder.

rav1e The fastest and safest AV1 encoder. Table of Content Overview Features Documentation Releases Building Dependency: NASM Release binary Unstable

Xiph.Org Foundation 3k Jan 3, 2023
A DHCP parser and encoder for DHCPv4/DHCPv6

dhcproto A DHCP parser and encoder for DHCPv4/DHCPv6. dhcproto aims to be a functionally complete DHCP implementation. Many common option types are im

BlueCat Engineering 80 Dec 11, 2022
An experimental gif encoder for Windows 10.

giffun An experimental gif encoder for Windows 10. Resources Based on "Techniques for GPU-based Color Quantization" (2019) by Matthias Trapp, Sebastia

Robert Mikhayelyan 3 Dec 22, 2021
Binary coverage tool without binary modification for Windows

Summary Mesos is a tool to gather binary code coverage on all user-land Windows targets without need for source or recompilation. It also provides an

null 384 Dec 30, 2022
Binary coverage tool without binary modification for Windows

Summary Mesos is a tool to gather binary code coverage on all user-land Windows targets without need for source or recompilation. It also provides an

null 381 Dec 22, 2022