Skip to content

fix(types): return None from Height::decrement_by on underflow - #397

Closed
Ruzzgar wants to merge 1 commit into
circlefin:mainfrom
Ruzzgar:fix/height-decrement-underflow
Closed

Ruzzgar wants to merge 1 commit into
circlefin:mainfrom
Ruzzgar:fix/height-decrement-underflow

Conversation

@Ruzzgar

@Ruzzgar Ruzzgar commented Sep 13, 2026

Copy link
Copy Markdown

The Height trait documents decrement_by as returning None on underflow:

/// Returns None if the height would be decremented below its minimum.
fn decrement_by(&self, n: u64) -> Option<Self>;

Arc's impl wraps saturating_sub in Some, so it never returns None — for n > height it yields Some(Height(0)). That contradicts the inherent decrement() (checked_sub) and increment_by (checked_add), and since the trait's default decrement() delegates here, the trait and inherent decrement() disagree at zero.

Switched to checked_sub. An existing test asserted the saturating result (Some(0) for an underflow); it now asserts None. cargo test -p arc-consensus-types passes.

The malachitebft Height trait documents decrement_by as returning None when
the height would go below its minimum. Arc's impl wraps saturating_sub in
Some, so it never returns None: decrementing below zero yields Some(Height(0)).

This disagrees with the inherent decrement() (checked_sub) and increment_by
(checked_add), and since the trait's default decrement() delegates to
decrement_by, the trait and inherent decrement() diverge at the zero boundary.

Use checked_sub. An existing test asserted the saturating result (Some(0) for
an underflow); it now asserts None.
@ZhiyuCircle

Copy link
Copy Markdown
Contributor

Hi @Ruzzgar,

Thank you for your interest in contributing to Arc Node, and apologies for the delay in getting back to this PR.

We're closing out the pull request backlog that predates our current contribution policy. This PR is being closed because it does not reference a GitHub issue. All PRs must reference an existing issue using the format Closes: #XXX, and the author must be assigned to that issue before the PR is opened.

This is not a judgement on the change itself. If you'd still like to land it:

  1. Open an issue describing the problem, or find the existing one
  2. Comment on the issue requesting assignment, and wait for maintainer approval
  3. Open a fresh PR once you have been assigned

Please see CONTRIBUTING.md for details. Thanks again for taking the time to contribute.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants