Skip to content

Create max array and list limit - #400

Open
stringhandler wants to merge 1 commit into
BlockstreamResearch:masterfrom
stringhandler:st-max-list-size
Open

Create max array and list limit#400
stringhandler wants to merge 1 commit into
BlockstreamResearch:masterfrom
stringhandler:st-max-list-size

Conversation

@stringhandler

Copy link
Copy Markdown
Contributor

Fixes #398

A type annotation with a huge array size or list bound made the compiler allocate a Vec proportional to that size with no cap. Because StructuralType::from() lowers every type during ordinary type unification, merely naming such a type was enough to trigger a multi-gigabyte allocation or a capacity-overflow panic, giving anything that compiles .simf a trivial DoS.

This adds MAX_ARRAY_SIZE and MAX_LIST_BOUND (both 2^16) and rejects anything larger during parsing, before any lowering happens. The cap is applied at all four places a size reaches a type: the [T; N] and List<T, N> annotations, plus array_fold::<f, N> and fold::<f, N>. A literal that overflows usize is now reported as too large rather than silently becoming 0. Tests cover each site and assert the reproduction no longer panics.

@stringhandler
stringhandler requested a review from delta1 as a code owner August 28, 2026 11:54
@Sahilgill24

Copy link
Copy Markdown

This PR also solves another bug similiar to the one it is fixing where a large array size being declared was looked at by the compiler as [u8;0]
ex.

  fn main() {
      let x: [u8; 99999999999999999999999999] = [];  
      let y: [u8; 0] = x;
  }

This code used to get compiled without any error code, but now with this PR it is also fixed :) .

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Unbounded array/list type sizes trigger excessive memory allocation

2 participants