Fix memory allocation in PSOperator and Type1FontProgram

[MaximPlusov]

Summary by CodeRabbit

• Bug Fixes
  • Strengthened PostScript operand validation: array size and loop iteration limits now prevent excessively large or malformed values, causing invalid loops to be skipped and avoiding processing errors or hangs when encountering problematic PDFs.
  • Added limits to nested PostScript execution in font programs to prevent excessive recursion, reducing risk of resource exhaustion and improving stability when parsing complex PDF content.

[coderabbitai]

Warning

Review limit reached

@MaximPlusov, we couldn't start this review because you've reached your PR review rate limit.

More reviews will be available in 56 minutes and 40 seconds. Learn how PR review limits work.

Your organization has run out of usage credits. Purchase more in the billing tab.

⌛ How to resolve this issue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans include higher PR review limits than trial, open-source, and free plans. In all cases, reviews become available again over time. During sustained high-volume PR review activity, CodeRabbit may temporarily slow when the next review becomes available.

Please see our Fair Usage Limits Policy for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 850ae608-5943-425e-b422-28a5e5f4c519

📥 Commits

Reviewing files that changed from the base of the PR and between 02d1e76 and 6e56680.

📒 Files selected for processing (2)

• src/main/java/org/verapdf/parser/postscript/PSOperator.java
• src/main/java/org/verapdf/pd/font/type1/Type1FontProgram.java

📝 Walkthrough

Walkthrough

Adds runtime safety checks: PSOperator now limits PostScript array sizes and for iteration counts via new constants; Type1FontProgram adds a recursion-depth limit for toExecute. Violations raise PostScriptException or skip execution per the new validations.

Changes

PostScript Resource Safety Limits

Layer / File(s)	Summary
Array size validation in PostScript array operator src/main/java/org/verapdf/parser/postscript/PSOperator.java	Defines MAX_PS_ARRAY_SIZE and MAX_PS_FOR_ITERATIONS, reads array size as Long, validates it is within [0, MAX_PS_ARRAY_SIZE], and throws PostScriptException on invalid sizes.
Iteration count limits in PostScript for operator src/main/java/org/verapdf/parser/postscript/PSOperator.java	Converts for parameters to long, validates increment and initial/limit direction, computes iteration count bounded by MAX_PS_FOR_ITERATIONS, and iterates with direction-aware termination or skips on invalid input.
Recursion depth protection in Type1 font PostScript execution src/main/java/org/verapdf/pd/font/type1/Type1FontProgram.java	Adds MAX_TO_EXECUTE_DEPTH and refactors toExecute() into an overload that threads a depth counter and throws PostScriptException when the limit is exceeded.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Poem

🐇 I bound the arrays and counted each hop,
I halted wild loops before they'd nonstop,
I tracked font calls down a safe little trail,
No endless recursion to make my nose pale —
Hooray for limits! 🥕✨

🚥 Pre-merge checks | ✅ 3 | ❌ 2

❌ Failed checks (2 warnings)

Check name	Status	Explanation	Resolution
Title check	⚠️ Warning	The title 'Fix memory allocation in PSOperator and Type1FontProgram' is somewhat related but misleading—the changes primarily introduce safety limits and recursion depth controls to prevent unbounded execution, not fix memory allocation issues.	Revise the title to better reflect the actual changes, such as 'Add execution safety limits to PSOperator and Type1FontProgram' or 'Introduce bounds checking for array sizes and loop iterations.'
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch type1_font

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 3

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@src/main/java/org/verapdf/parser/postscript/PSOperator.java`:
- Around line 588-590: In PSOperator (the block checking increment/initial/limit
where it currently does "if (increment == 0 || (increment > 0 && initial >
limit) || (increment < 0 && initial < limit)) { throw new
PostScriptException(...); }"), change the behavior so only a zero increment
throws PostScriptException; remove the throw for direction-mismatch cases and
instead treat them as no-op loops by returning zero iterations (or setting the
loop count/iterator to 0) when (increment > 0 && initial > limit) or (increment
< 0 && initial < limit); keep the check and throw for increment == 0, and ensure
you return the appropriate zero-iteration value from the surrounding method so
callers handle the no-op correctly.
- Around line 540-543: The code narrows the value from
getTopNumber().getInteger() to an int (arraySize) before checking range,
allowing very large integers to wrap; change the validation to check the
BigInteger/long magnitude against MAX_PS_ARRAY_SIZE and non-negativity before
converting to int (i.e., obtain the BigInteger/Number from
getTopNumber().getInteger(), compare it to BigInteger.valueOf(MAX_PS_ARRAY_SIZE)
and zero, and only then call intValueExact()/intValue() to assign to arraySize
or throw PostScriptException if out of range), updating any surrounding logic in
the method in PSOperator where arraySize is used.

In `@src/main/java/org/verapdf/pd/font/type1/Type1FontProgram.java`:
- Around line 195-196: In Type1FontProgram change the recursion guard so it
throws when depth is greater than or equal to the limit: replace the current
condition using depth and MAX_TO_EXECUTE_DEPTH (currently "depth >
MAX_TO_EXECUTE_DEPTH") with a check that fails on equality as well (e.g., "depth
>= MAX_TO_EXECUTE_DEPTH") so the PostScriptException in the toExecute recursion
path is raised at the intended maximum; update the clause that throws
PostScriptException("Type 1 font program exceeded toExecute recursion depth")
accordingly.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 3e51e25a-5fff-46b0-a002-e29c819ca54f

📥 Commits

Reviewing files that changed from the base of the PR and between 5164caf and e4c42c0.

📒 Files selected for processing (2)

• src/main/java/org/verapdf/parser/postscript/PSOperator.java
• src/main/java/org/verapdf/pd/font/type1/Type1FontProgram.java