profile
viewpoint
jean-airoldie Sessions should be nested with care.

jean-airoldie/abi_stable_crates 0

Rust-to-Rust ffi,ffi-safe equivalents of std types,and creating libraries loaded at startup.

jean-airoldie/alexandrie 0

An alternative crate registry, implemented in Rust.

jean-airoldie/async-compression 0

Adaptors between compression crates and Rust's async IO types

jean-airoldie/async-tungstenite 0

Async binding for Tungstenite, the Lightweight stream-based WebSocket implementation

jean-airoldie/bincode 0

A binary encoder / decoder implementation in Rust.

jean-airoldie/byte-slice-cast 0

Safely cast slices of one built-in fundamental number type to another

jean-airoldie/caps-rs 0

A pure-Rust library to work with Linux capabilities

jean-airoldie/cargo 0

The Rust package manager

jean-airoldie/caring 0

The `Shared<T>` struct for cross-process shared-memory objects of type `T`

startedopcm/pcm

started time in 5 days

create barnchjean-airoldie/quinn

branch : idle_timeout_debug

created branch time in 14 days

issue commentsdroege/byte-slice-cast

Support primitive array

Thx!

jean-airoldie

comment created time in a month

pull request commentsdroege/byte-slice-cast

Add support for primitive arrays

Fixes #19.

jean-airoldie

comment created time in a month

issue openedsdroege/byte-slice-cast

Support primitive array

Would you be open to supporting primitive arrays? Since the layout appear to be well defined, it should be safe to do so.

created time in a month

PR opened sdroege/byte-slice-cast

Add support for primitive arrays
  • Add support for primitive arrays via const generics.
  • Add a few basic tests.
  • Add Cargo.lock to the .gitignore so the lockfile doesn't get accidentally added.

Since the layout of arrays seem well defined, this should be safe to do. However this will increase the minimum compiler version requirements because of the usage of const generic.

I was pretty lazy on the tests and only added the bare minimum. The type name is not ideal either due to stringify not picking up the generic constant.

+127 -0

0 comment

2 changed files

pr created time in a month

create barnchjean-airoldie/byte-slice-cast

branch : array

created branch time in a month

fork jean-airoldie/byte-slice-cast

Safely cast slices of one built-in fundamental number type to another

fork in a month

push eventjean-airoldie/rust-dec

jean-airoldie

commit sha e914552ac6c312d2b9e80a93903da1fc7daa633b

Unnest bench imports

view details

push time in a month

pull request commentMaterializeInc/rust-dec

dec: Expand benchmarks

LGTM modulo unnesting imports.

I'm not exactly sure of what that means. I'm guessing you mean that you prefer a single import group per line.

jean-airoldie

comment created time in a month

push eventjean-airoldie/rust-dec

jean-airoldie

commit sha d308c7362848e23f60f4cd416b02769f2288f274

Expand benchmarks * Add benchmarks for basic ops (add, sub, mul, div, etc.) for the decimal types. * Use seeded rng for reproducible results. * Use a longer measurement period for more consistant results.

view details

push time in a month

startedgcc-mirror/gcc

started time in a month

PR opened MaterializeInc/rust-dec

dec: Fix clippy warnings

Pretty self describing.

+35 -31

0 comment

4 changed files

pr created time in a month

create barnchjean-airoldie/rust-dec

branch : clippy

created branch time in a month

PR opened MaterializeInc/rust-dec

Expand benchmarks

This expands the benchmarks for the various number types. For the choice of operations, I used what was already benchmarked and I added functions I expect to be commonly used. Feel free to suggest anything else that could be relevent. I also wasn't too sure what sizes of Decimal<T> to test for.

One problem with the decimal generation approach I used is that the numbers are totally random and thus don't really follow any real world statistical distribution. This shouldn't be a big problem as long as the benchmark are only used to gauge relative improvement in performance etc.

+211 -145

0 comment

2 changed files

pr created time in a month

push eventjean-airoldie/rust-dec

jean-airoldie

commit sha d26bf8acda1161e6d52901f706ef8da01db71798

Improve benchmarks

view details

push time in a month

create barnchjean-airoldie/rust-dec

branch : bench

created branch time in a month

fork jean-airoldie/rust-dec

libdecnumber bindings for the Rust programming language

fork in a month

issue commentMaterializeInc/rust-dec

Use C repr for fixed width types

Using #[repr(transparent)] would also work to be clear.

jean-airoldie

comment created time in a month

issue commentMaterializeInc/rust-dec

Use C repr for fixed width types

Too slow basically. I want to cast a bigass trusted byte slice into a &[Decimal64] directly, without having to allocate or iterate etc.

Isn't the underlying Decimal64 etc. already repr(C) anyway?

jean-airoldie

comment created time in a month

issue openedMaterializeInc/rust-dec

Use C repr for fixed width types

Would you consider adding #[repr(C)] to the fixed width decimal types so they can be safely cast to and from bytes?

I know the ::from_le_bytes & ::to_le_bytes methods are available for that purpose, but when casting bytes into a decimal slice, its not possible to use such methods.

created time in a month

issue commentpaupino/rust-decimal

Decimal::deserialize can panic

Would something like this work for you? https://github.com/paupino/rust-decimal/compare/bug/deserialize-panic?expand=1

This allows scales < 32 to be supported and automatically rounded. With this implementation, scales >= 32 are undefined behavior. It won't panic, but it probably won't be correct. That being said, I could add some more aggressive rounding logic in there potentially to allow for scales up to ~58 (i.e. at that point in time, the number will be 0).

I think this is better than panicking. I don't think you necessarily need to support scales greater than 28 because they shouldn't occur normally. They can only occur during fuzzing or someone with malicious intent.

jean-airoldie

comment created time in a month

issue commentpaupino/rust-decimal

Decimal::deserialize can panic

For instance, if a scale up to 32 could be supported, then the Decimal::scale method would never UB. But like i said, idk the implementation details of Decimal, so im guessing this isn't possible.

jean-airoldie

comment created time in a month

issue commentpaupino/rust-decimal

Decimal::deserialize can panic

The ideal solution would be to make the decimal type work for any scale, but I'm guessing its not possible since 28 is between 2^4 and 2^5.

What I mean, is to truncate the scale when interpreting it, so that it never exceeds the maximum value, so that the Decimal is defined for any combination of bytes.

jean-airoldie

comment created time in a month

issue commentpaupino/rust-decimal

Decimal::deserialize can panic

Yeah i think a checked deserialization could work. I think you should add some doc on deserialize to make it explicit that it can panic. However I think that making a function panic is a breaking change, even if the previous behavior was UB.

I think that dividing it down to a supported scale would probably work also. If its significantly slower it could be used by a 3rd party to cause DOS. Idk if its considered a breaking change.

The ideal solution would be to make the decimal type work for any scale, but I'm guessing its not possible since 28 is between 2^4 and 2^5.

jean-airoldie

comment created time in a month

issue openedpaupino/rust-decimal

Decimal::deserialize can panic

The PR https://github.com/paupino/rust-decimal/pull/433 introduced a panic in the deserialize method: https://github.com/paupino/rust-decimal/blob/c74bd40701cce99b264af6b9af2e66d0f66251f1/src/decimal.rs#L710\

This means that one cannot receive raw serialized decimals from a untrusted 3rd party. I'm also assuming that casting raw bytes to Decimal, even with the repr(C) freature enabled is UB.

Do you think it would be possible to make casting bytes to a Decimal type not UB? My specific use case is for binary serialization where serde is too slow.

created time in a month

issue commentpaupino/rust-decimal

Overflow when serializing weird values

This test makes the fmt::Display call panic:

#[test]
fn it_can_serialize_weird_values() {
    let tests = [
        [1u8, 0, 30, 206, 97, 81, 216, 182, 20, 30, 165, 78, 18, 155, 169, 62],
    ];
    for &bytes in &tests {
        let dec = Decimal::deserialize(bytes);
        let string = format!("{:.9999}", dec);
        let dec2 = Decimal::from_str(&string).unwrap();
        assert_eq!(dec, dec2);
    }
}
jean-airoldie

comment created time in 2 months

issue commentpaupino/rust-decimal

Overflow when serializing weird values

Seems like the internal display implementation can panic this way, which can cause some weird panicked while panicking issues. https://github.com/paupino/rust-decimal/blob/805473bfd4f37e5e895f3229ecca52cb17a223cc/src/decimal.rs#L2056

jean-airoldie

comment created time in 2 months

issue commentpaupino/rust-decimal

Overflow when serializing weird values

I'm guessing that there are values that can be constructed via Decimal::deserialize that cannot be constructed via Decimal::from_str, which explains why the test suit didn't pick those up.

jean-airoldie

comment created time in 2 months

issue openedpaupino/rust-decimal

Overflow when serializing weird values

While doing some fuzzing, I found this weird value that fails to serialize.

#[test]
fn it_can_serialize_weird_values() {
    let tests = [
        [1u8, 0, 30, 206, 97, 81, 216, 182, 20, 30, 165, 78, 18, 155, 169, 62],
    ];
    for &bytes in &tests {
        let dec = Decimal::deserialize(bytes);
        let bytes = bincode::serialize(&dec).unwrap();
        let dec2 = bincode::deserialize(&bytes).unwrap();
        assert_eq!(dec, dec2);
    }
}

Fails with:

---- it_can_serialize_weird_values stdout ----
thread 'it_can_serialize_weird_values' panicked at 'called `Result::unwrap()` on an `Err` value: CapacityError: insufficient capacity', /home/REDACTED/.cargo/registry/src/github.com-1ecc6299db9ec823/arrayvec-0.5.2/src/array_string.rs:165:26
stack backtrace:
   0: rust_begin_unwind
             at /rustc/c8dfcfe046a7680554bf4eb612bad840e7631c4b/library/std/src/panicking.rs:515:5
   1: core::panicking::panic_fmt
             at /rustc/c8dfcfe046a7680554bf4eb612bad840e7631c4b/library/core/src/panicking.rs:92:14
   2: core::result::unwrap_failed
             at /rustc/c8dfcfe046a7680554bf4eb612bad840e7631c4b/library/core/src/result.rs:1599:5
   3: core::result::Result<T,E>::unwrap
             at /rustc/c8dfcfe046a7680554bf4eb612bad840e7631c4b/library/core/src/result.rs:1281:23
   4: arrayvec::array_string::ArrayString<A>::push
             at /home/REDACTED/.cargo/registry/src/github.com-1ecc6299db9ec823/arrayvec-0.5.2/src/array_string.rs:165:9
   5: rust_decimal::str::to_str_internal
             at ./src/str.rs:60:13
   6: rust_decimal::serde::<impl serde::ser::Serialize for rust_decimal::decimal::Decimal>::serialize
             at ./src/serde.rs:177:34
   7: bincode::internal::serialized_size
             at /home/REDACTED/.cargo/registry/src/github.com-1ecc6299db9ec823/bincode-1.3.3/src/internal.rs:45:18
   8: bincode::internal::serialize
             at /home/REDACTED/.cargo/registry/src/github.com-1ecc6299db9ec823/bincode-1.3.3/src/internal.rs:31:27
   9: bincode::config::Options::serialize
             at /home/REDACTED/.cargo/registry/src/github.com-1ecc6299db9ec823/bincode-1.3.3/src/config/mod.rs:179:9
  10: bincode::serialize
             at /home/REDACTED/.cargo/registry/src/github.com-1ecc6299db9ec823/bincode-1.3.3/src/lib.rs:110:5
  11: decimal_tests::it_can_serialize_weird_values
             at ./tests/decimal_tests.rs:142:21
  12: decimal_tests::it_can_serialize_weird_values::{{closure}}
             at ./tests/decimal_tests.rs:136:1
  13: core::ops::function::FnOnce::call_once
             at /rustc/c8dfcfe046a7680554bf4eb612bad840e7631c4b/library/core/src/ops/function.rs:227:5
  14: core::ops::function::FnOnce::call_once
             at /rustc/c8dfcfe046a7680554bf4eb612bad840e7631c4b/library/core/src/ops/function.rs:227:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

created time in 2 months

more