fix: replace transmute UB in error constructors with safe alternatives by LuciferYang · Pull Request #58 · nlordell/ethnum-rs

LuciferYang · 2026-04-18T17:39:15Z

Summary

pie() used unsafe { mem::transmute(kind) } to create a ParseIntError from an IntErrorKind, and tfie() used unsafe { mem::transmute(()) } to create a TryFromIntError. Both rely on unstable internal layouts of standard library types.

Starting with Rust nightly nightly-2026-04-18 (commit e9e32aca5, 2026-04-17) on Linux x86_64, TryFromIntError grew from 0 to 1 byte, causing tfie() to fail at compile time:

error[E0512]: cannot transmute between types of different sizes, or dependently-sized types
  --> src/error.rs:16:14
   |
16 |     unsafe { mem::transmute(()) }
   |              ^^^^^^^^^^^^^^
   |
   = note: source type: `()` (0 bits)
   = note: target type: `TryFromIntError` (8 bits)

pie() still compiles today but is equally fragile — it depends on IntErrorKind and ParseIntError having the same layout.

Changes

Replace both functions with safe stdlib operations:

pie(kind): unsafe { mem::transmute(kind) } → match on IntErrorKind and trigger real parse errors via from_str_radix. Stays const fn.
tfie(): unsafe { mem::transmute(()) } → u8::try_from(-1i8).unwrap_err(). No longer const fn since TryFrom isn't const-stable yet, but no call site uses it in const context.

Other changes per review feedback:

Use unreachable!() for the wildcard match arm (internal-only input)
Remove IntErrorKind::Zero from pie() (not used by the library)

Verification

All 207 existing tests pass on stable, nightly (macOS), and nightly (Linux x86_64 via Docker)
Confirmed the original code fails to compile on nightly-2026-04-18 Linux x86_64
Confirmed the fix compiles and passes on nightly-2026-04-18 Linux x86_64
All CI lint checks pass: cargo fmt, cargo clippy (workspace, serde, macros, llvm-intrinsics)

`tfie()` used `mem::transmute(())` to create a `TryFromIntError`, and `pie()` used `mem::transmute(kind)` to create a `ParseIntError`. Both rely on unstable internal layouts of standard library types. Starting with Rust nightly > 2026-04-16 on Linux x86_64, `TryFromIntError` grew from 0 to 1 byte, making the `tfie()` transmute a compilation error (size mismatch). `pie()` still compiles today but is equally fragile. Replace both with safe stdlib operations: - `tfie()`: `u8::try_from(-1i8).unwrap_err()` - `pie()`: match on `IntErrorKind` and trigger real parse errors The functions are no longer `const fn` because the safe alternatives call non-const methods. No existing call site uses them in const context, so this is a compatible change. All 207 existing tests continue to pass on both stable and nightly.

nlordell · 2026-04-19T12:58:11Z

+        IntErrorKind::PosOverflow => u8_parse_error("256"),
+        IntErrorKind::NegOverflow => i8_parse_error("-129"),
+        IntErrorKind::Zero => zero_parse_error(),
+        _ => u8_parse_error("?"), // fallback for future variants


This should be unreachable!() IMO - the input kind is limited to the uses of this function internal to the library, so we know that this branch will never be reached.

Done, switched to unreachable\!().

nlordell · 2026-04-19T13:06:08Z

+fn u8_parse_error(s: &str) -> ParseIntError {
+    s.parse::<u8>().unwrap_err()
+}


If we use https://doc.rust-lang.org/stable/std/primitive.u8.html#method.from_str_radix, then the function can stay const:

const fn u8_parse_error(s: &str) -> std::num::ParseIntError { let Err(err) = u8::from_str_radix(s, 10) else { panic!("not a parse error!"); }; err } fn main() { let x = u8_parse_error("-1"); println!("{x:?}!"); }

Same for the i8_parse_error function, (allowing pie to stay const).

Nice, from_str_radix works perfectly here. pie() and the helpers are const fn again. tfie() stays non-const since TryFrom is not const-stable yet, but no call site needs it in const context anyway.

nlordell · 2026-04-19T13:10:50Z

+        IntErrorKind::InvalidDigit => u8_parse_error("?"),
+        IntErrorKind::PosOverflow => u8_parse_error("256"),
+        IntErrorKind::NegOverflow => i8_parse_error("-129"),
+        IntErrorKind::Zero => zero_parse_error(),


The Zero is only used in the test below, so it can be removed.

Removed. Also dropped the NonZeroU32 import that was only there for the Zero test.

nlordell

Generally agree with the change, thanks very much!

Left some small comments that I want to be resolved before merging. I can cut a 1.5.3 release afterwards as well.

- Use u8::from_str_radix / i8::from_str_radix to keep pie() and helpers const - Replace wildcard fallback with unreachable!() since kind is internal - Remove IntErrorKind::Zero from pie() match (only used in tests) - Move Zero variant test to a separate test function

The Zero variant was removed from pie() match. The test was verifying stdlib's NonZeroU32 parsing, not any library functionality.

LuciferYang · 2026-04-20T15:31:15Z

Thank you @nlordell ~

nlordell · 2026-04-20T15:45:50Z

Thanks again for the contribution! Released: https://crates.io/crates/ethnum/1.5.3

LuciferYang · 2026-04-20T15:47:57Z

Thank you again @nlordell

## Summary Upgrade transitive dependency `ethnum` from 1.5.2 to 1.5.3 and revert the nightly toolchain pin from #6570. Dependency chain: `lance-arrow` → `jsonb 0.5.6` → `ethnum 1.5.3` ## Root Cause `ethnum 1.5.2` used `unsafe { mem::transmute(()) }` to construct `TryFromIntError`, which broke on nightly > 2026-04-16 when `TryFromIntError` grew from 0 to 1 byte on Linux x86_64. `ethnum 1.5.3` ([nlordell/ethnum-rs#58](nlordell/ethnum-rs#58)) replaced all transmute with safe stdlib operations, so the pin is no longer needed. ## Test plan - [x] Verified ethnum 1.5.3 compiles on `nightly-2026-04-18` (the version that broke 1.5.2) in Docker Linux x86_64 - [x] `linux-build` job should pass with unpinned nightly

…lar#5287) The causal chain here is: - oss-fuzz wants to fuzz with sanitizers turned on (a generally good idea) - rust sanitizer builds have to be both unified builds and _nightly_ builds (the sanitizer flag is rust-nightly-only) - our rust build depends on `ethnum`, specifically version `1.5.0` - `ethnum 1.5.0` has a bug in it that our pinned rust `1.95.0` doesn't mind, but rust nightly rejects; it's [fixed](nlordell/ethnum-rs#58) in `1.5.3` - `1.5.3` otherwise seems to work fine and the release notes show only some optimizations and bugfixes. - There's some _theoretical_ potential for divergence (eg. where observable bugs in `ethnum` were fixed: nlordell/ethnum-rs#44) but .. I don't see any way for this to actually get hit in practice: this PR is a bump to the `ethnum` dependency _outside_ any of the soroban production-build deps (they all have their own pinned ones in production builds) and that dependency only exists, as far as I can tell, because `stellar-xdr` links in `ethnum` to be able to do u256/i256 ops, which .. we don't actually use anywhere in the non-soroban-host rust code (eg. the bridge helpers). There's no use of `i256`, `u256`, `I256`, `U256`, or `ethnum` in any rust code in our tree outside the soroban crates. So I don't _think_ this can cause any divergence in production. But, you know, one can always miss something! If that very narrow possible I-don't-see-how risk is still too much to swallow we can wait for a protocol boundary, but this will I think basically block oss-fuzz integration until it's resolved. (There's another option which is to turn off the sanitizers, I guess; I am going to try that in the meantime to see if I can get it working, but I'm not sure how likely that is nor whether it's a particularly good idea longer-term.)

LuciferYang mentioned this pull request Apr 18, 2026

ci: pin nightly toolchain to 2026-04-16 for ethnum 1.5.2 compat lance-format/lance#6570

Merged

1 task

jackye1995 mentioned this pull request Apr 19, 2026

ci: ethnum 1.5.2 fails to compile on Rust nightly >= 1.97.0 lance-format/lance#6573

Open

nlordell reviewed Apr 19, 2026

View reviewed changes

LuciferYang added 2 commits April 19, 2026 21:29

remove parse_int_error_zero test that only tests stdlib behavior

f031067

The Zero variant was removed from pie() match. The test was verifying stdlib's NonZeroU32 parsing, not any library functionality.

nlordell approved these changes Apr 20, 2026

View reviewed changes

nlordell merged commit 87e3457 into nlordell:main Apr 20, 2026
1 check passed

LuciferYang mentioned this pull request Apr 20, 2026

fix: upgrade ethnum 1.5.2 to 1.5.3 and unpin nightly toolchain lance-format/lance#6578

Merged

2 tasks

This was referenced Apr 20, 2026

Update transitive dependency ethnum to 1.5.3 stellar/rs-soroban-sdk#1838

Closed

Update dependency ethnum to 1.5.3 stellar/rs-stellar-xdr#525

Merged

leif-hesperides mentioned this pull request Apr 21, 2026

ethnum <1.5.3 fails to compile since nightly-2026-04-18 pola-rs/polars#27369

Closed

Zentrik mentioned this pull request May 11, 2026

[bot-automerge] polars v1.40.1 conda-forge/polars-feedstock#366

Merged

3 tasks

graydon mentioned this pull request May 21, 2026

Bump ethnum to placate nightly, for unified build, for oss-fuzz stellar/stellar-core#5287

Merged

cmdlineluser mentioned this pull request Jun 3, 2026

Does not compile with rustc 1.98.0-nightly pola-rs/polars#27863

Closed

2 tasks

This was referenced Jun 4, 2026

1.97 beta regression due to TryFromIntError changing size rust-lang/rust#157363

Closed

Failure to build with 1.97-beta due to a change in TryFromIntError #60

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

fix: replace transmute UB in error constructors with safe alternatives#58

fix: replace transmute UB in error constructors with safe alternatives#58
nlordell merged 3 commits into
nlordell:mainfrom
LuciferYang:fix-transmute-ub

LuciferYang commented Apr 18, 2026 •

edited

Loading

Uh oh!

nlordell Apr 19, 2026

Uh oh!

LuciferYang Apr 19, 2026

Uh oh!

nlordell Apr 19, 2026

Uh oh!

LuciferYang Apr 19, 2026

Uh oh!

nlordell Apr 19, 2026 •

edited

Loading

Uh oh!

LuciferYang Apr 19, 2026

Uh oh!

nlordell left a comment

Uh oh!

Uh oh!

LuciferYang commented Apr 20, 2026

Uh oh!

nlordell commented Apr 20, 2026

Uh oh!

LuciferYang commented Apr 20, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

LuciferYang commented Apr 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Changes

Verification

Uh oh!

nlordell Apr 19, 2026

Choose a reason for hiding this comment

Uh oh!

LuciferYang Apr 19, 2026

Choose a reason for hiding this comment

Uh oh!

nlordell Apr 19, 2026

Choose a reason for hiding this comment

Uh oh!

LuciferYang Apr 19, 2026

Choose a reason for hiding this comment

Uh oh!

nlordell Apr 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

LuciferYang Apr 19, 2026

Choose a reason for hiding this comment

Uh oh!

nlordell left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

LuciferYang commented Apr 20, 2026

Uh oh!

nlordell commented Apr 20, 2026

Uh oh!

LuciferYang commented Apr 20, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

LuciferYang commented Apr 18, 2026 •

edited

Loading

nlordell Apr 19, 2026 •

edited

Loading