Hey 馃憢
Found a panic in the ACN two's complement encoder in the Rust runtime while writing round-trip tests for asn1rust.
How to reproduce:
let mut buf = [0u8; 16];
let mut bs = BitStream::new(&mut buf);
acn::acn_enc_int_twos_complement_const_size(&mut bs, i64::MIN, 64);
// panics: "attempt to subtract with overflow" at acn.rs:372
Root cause:
Line 372 in asn1rust/src/acn.rs:
let abs_val = (int_val.wrapping_neg() - 1) as Asn1SccUint;
i64::MIN.wrapping_neg() returns i64::MIN (the value has no positive i64 representation). The subsequent - 1 is an unchecked subtraction that overflows in Rust debug mode. The C equivalent wraps silently.
Expected behavior:
The encoder should produce the correct two's complement bit pattern for any value in the i64 range, including the minimum.
Impact:
Any ASN.1 INTEGER type whose range includes the minimum 64-bit signed value will panic during ACN encoding in the Rust backend. The C backend handles this correctly.
Happy to send a fix if this is confirmed 馃檹
Hey 馃憢
Found a panic in the ACN two's complement encoder in the Rust runtime while writing round-trip tests for
asn1rust.How to reproduce:
Root cause:
Line 372 in
asn1rust/src/acn.rs:i64::MIN.wrapping_neg()returnsi64::MIN(the value has no positive i64 representation). The subsequent- 1is an unchecked subtraction that overflows in Rust debug mode. The C equivalent wraps silently.Expected behavior:
The encoder should produce the correct two's complement bit pattern for any value in the i64 range, including the minimum.
Impact:
Any ASN.1 INTEGER type whose range includes the minimum 64-bit signed value will panic during ACN encoding in the Rust backend. The C backend handles this correctly.
Happy to send a fix if this is confirmed 馃檹