[damnbrocrazy-svg]

Description

Converting a giga/thicc value to chad/gigachad read its low 32 bits. For example, assigning 5000000000 to a double printed 705032704.000000; multiplying it by 2.0 printed 1410065408.000000.

Preserve the integer expression's width before floating conversion. The float/double evaluators route wide integer expressions through evaluate_expression_long, while the integer operand helpers do the same for mixed arithmetic. The type guard keeps mixed floating expressions in floating-point evaluation, and the existing pointer exclusion and unsigned-32 operand behavior remain intact. The float helper converts directly from the wide integer, avoiding an intermediate double and double rounding.

Two language-level regression fixtures cover both widths and signs, assignment and literals, mixed operations and both operand orders, 32-bit boundaries, the minimum signed 64-bit value, a float halfway-point case, nested expressions, array/pointer reads, and single evaluation of increment/index/function-call side effects. Both final fixtures fail against a separately rebuilt unchanged upstream 4988c99 with normal exits and no parsing errors, and pass with this patch.

Validation on Ubuntu 24.04 / WSL2, in an isolated workspace:

• make test: 548 passed, 5 skipped (optional raylib integration tests).
• make format-check, make cppcheck and make tidy: passed.
• make valgrind: passed across all 487 fixtures (zero reported errors).

AI assistance: implementation and verification were performed with Codex, with additional read-only AI-assisted source analysis. This is disclosed as in the issue discussion; no independent human review is implied.

Related Issue

Fixes #372

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update
• Performance improvement
• Refactor

Checklist

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have documented my changes in the code or documentation
• I have added tests that prove my change works, at the lowest appropriate layer (test_cases/*.brainrot for language-visible behavior; a host-side C test wired into make test for internal APIs Brainrot source cannot reach). Required for every bug fix, feature, refactor, performance change, and breaking change — not optional, not "if applicable". See CONTRIBUTING.md ("TESTS ARE MANDATORY").
• Those tests cover the happy path, the original bug (for fixes), error cases, edge cases, and adversarial cases. If the existing harness could not reach the behavior, I extended it or added a lower-level test.
• If this PR cannot affect program behavior (docs/comments/license only), I explained that in the Description instead of skipping the items above in silence
• I have run make format-check locally (or make format to fix)
• I have run the unit tests locally
• I have run the valgrind memory tests locally
• All new and existing tests pass

Error/rejection paths are covered by the existing passing suite; the added fixtures focus on the numeric conversion regression. The docs-only checklist item does not apply.

[mradul-bansal]

Hi, I’m considering a Brainrot contribution for the Build 2026 × ByteAsk challenge. I noticed PR #394 is already addressing issue #372 with regression tests, so I won’t duplicate that work. Is there another open starter-to-medium issue you’d recommend that is available for a new contributor? I’ll follow the project’s required testing and disclosure rules, and wait for your guidance before starting.

[leo-aa88]

Hi, I’m considering a Brainrot contribution for the Build 2026 × ByteAsk challenge. I noticed PR #394 is already addressing issue #372 with regression tests, so I won’t duplicate that work. Is there another open starter-to-medium issue you’d recommend that is available for a new contributor? I’ll follow the project’s required testing and disclosure rules, and wait for your guidance before starting.

Feel free to pick any

[leo-aa88]

LGTM

[mradul-bansal]

Hi, I’m considering a Brainrot contribution for the Build 2026 × ByteAsk challenge. I noticed PR #394 is already addressing issue #372 with regression tests, so I won’t duplicate that work. Is there another open starter-to-medium issue you’d recommend that is available for a new contributor? I’ll follow the project’s required testing and disclosure rules, and wait for your guidance before starting.

Feel free to pick any

Thanks! I’d like to take issue #379. I’ll trace the shared formatting behavior and keep the fix focused on making %% produce a single % whether or not format arguments remain. I’ll add regression coverage for the no-argument case and for %% after the last argument is consumed, then run the project’s required checks. Please let me know if someone has already started on it.