fix(strings): (int) over a numeric string caps like PHP instead of wrapping

[Guikingone]

Found while investigating #953, which lists (int)$s as one of the paths into the unbounded
__rt_cstr buffer. The buffer is a separate problem; on the way there, the values turned out
to be wrong.

PHP applies two different rules

A float value is reduced modulo 2^64. A numeric string is capped. elephc was routing
the string through the float rule.

(int)1e19      // php: -8446744073709551616   — the float rule, and elephc agrees
(int)"1e19"    // php:  9223372036854775807   — the STRING rule

__rt_php_float_to_int implements the float rule correctly and is untouched; __rt_str_to_int
just should not have been calling it.

What was wrong

expression	PHP	before
(int)"1e19"	9223372036854775807	-8446744073709551616
(int)"-1e19"	-9223372036854775808	8446744073709551616
(int)"1.8e19"	9223372036854775807	-446744073709551616
(int)"1e100"	9223372036854775807	0
(int)"1e308"	9223372036854775807	0
(int)str_repeat("1", 310)	0	9223372036854775807
(int)("-" . str_repeat("1", 310))	0	-9223372036854775808

The wrapping cases are the ones that matter: (int)$_GET['page'] on an oversized value produced
a large negative number instead of PHP_INT_MAX, with no warning.

The last two are the reverse failure, and they sit on the integer-form path: strtoll
saturates a 310-digit integer to PHP_INT_MAX, but PHP classifies a string whose value
overflows the double as IS_DOUBLE, and INF casts to 0. So the non-finite check has to run
before the integer/float form choice — that string is integer-form.

The fix

• Non-finite parsed double → 0, checked first, for either form.
• Float-form → cap. AArch64 needs no bounds of its own, because fcvtzs saturates by
  definition, which is exactly PHP's cap for every finite double. x86_64's cvttsd2si reports
  the "integer indefinite" pattern instead — already correct for a negative overflow, so only a
  positive one is turned into PHP_INT_MAX.
• Integer-form → unchanged, strtoll's exact value.

That last point is load-bearing and has its own fixture: 2^53 + 1 is exactly representable as
an integer but not as a double, so capping the parsed double instead of taking strtoll's
answer would round (int)"9007199254740993" down by one.

Verification

• 23 shapes byte-identical to PHP 8.5.10, spanning the int64 boundary (…807, …808, …809),
  the finite/INF boundary (309 vs 310 digits), both signs, leading whitespace, and float-form
  spellings.
• The same values through intval(), settype(), mixed-array arithmetic and loose comparison.
• Both fixtures fail without the fix.
• x86_64 assembles clean for x86_64-unknown-linux-gnu; --lib 1680, strings:: 392 and
  operators:: 127 pass.

🤖 Generated with Claude Code

https://claude.ai/code/session_01KSAAWPyNBq6dP2b5puN3wr

[greptile-apps]

Confidence Score: 5/5

The PR appears safe to merge; the previous documentation requirement is now fully satisfied and no new actionable issue remains.

Findings

1.  Runtime semantics lack documentation ▶

Fix with agent prompt

### Issue 1
src/codegen_support/runtime/numeric.rs:undefined-84
This adds a separate numeric-string conversion helper and changes string casts to cap values instead of applying the float-value wrapping rule. The repository requires compiler-internal runtime changes to be documented in the relevant `docs/internals/` page. Please document why numeric strings use the capping helper while float values retain modulo-2^64 conversion; this requirement must be satisfied before merging.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

Summary

This PR corrects numeric-string-to-integer conversion so finite overflow is capped to PHP’s integer range rather than routed through the float-value wrapping rule.

• Adds a shared, target-aware capping helper for AArch64 and x86_64.
• Handles non-finite parsed values before selecting integer-form or float-form conversion.
• Preserves exact integer-form values that cannot be represented precisely as doubles.
• Adds regression coverage for overflow boundaries, very large strings, and both target implementations.
• Documents why numeric strings and float values require different conversion helpers.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[Numeric string] --> B[Parse with strtod and strtoll]
    B --> C{Parsed double finite?}
    C -- No --> D[Return 0]
    C -- Yes --> E{strtod consumed more input?}
    E -- No: integer form --> F[Return exact strtoll value]
    E -- Yes: float form --> G[Call numeric-string cap helper]
    G --> H{Target}
    H -- AArch64 --> I[fcvtzs saturation]
    H -- x86_64 --> J[cvttsd2si and correct positive overflow]
    I --> K[Return capped integer]
    J --> K

Loading

_{Reviews (4) · Last reviewed commit: "docs(internals): record the two double-t..."}

[Guikingone]

The one red check here is not this change. Curl Codegen Tests (macos-aarch64 4/4) fails on curl_monitor_excludes_write_callback_cpu_from_network_wait, a timing assertion, and it has now failed twice in a row on this runner with the same shape:

run 1:  control 372625 ns → in-callback 7815417 ns
run 2:  control 432417 ns → in-callback 7418999 ns

against WAIT_SLACK_NS = 5_000_000. The defect that assertion guards produced 133.9 ms against a 1.2 ms control — 18x further out than either sample here. This is loopback scheduling jitter on a shared runner, not billed callback CPU: the burn is ~130 ms and would show as that.

This PR touches __rt_str_to_int and adds __rt_php_float_to_int_cap; nothing on the curl monitoring path. Build & Test is the aggregation gate and fails only because that shard did.

#1024 is exactly this: it raises the bound to 20 ms — better than 2x over these samples, still ~6.6x below the gap the defect produces — and, because widening a tolerance can only move a test toward vacuous, it adds an assertion that the in-callback burn measured from the capture exceeds the slack by 2x, so a fully misbilled callback can never satisfy the comparison. Its comment already cites the 7.80 ms sample from run 1; run 2's 7.42 ms is a third data point.

Re-running does not help — it has now been re-run once and reproduced. #1024 should land first, then this one goes green on a rebase.

[greptile-apps]

Runtime semantics lack documentation

This adds a separate numeric-string conversion helper and changes string casts to cap values instead of applying the float-value wrapping rule. The repository requires compiler-internal runtime changes to be documented in the relevant docs/internals/ page. Please document why numeric strings use the capping helper while float values retain modulo-2^64 conversion; this requirement must be satisfied before merging.

Context Used: AGENTS.md (source)

Prompt To Fix With AI

This is a comment left during a code review.
Path: src/codegen_support/runtime/numeric.rs
Line: 84

Comment:
**Runtime semantics lack documentation**

This adds a separate numeric-string conversion helper and changes string casts to cap values instead of applying the float-value wrapping rule. The repository requires compiler-internal runtime changes to be documented in the relevant `docs/internals/` page. Please document why numeric strings use the capping helper while float values retain modulo-2^64 conversion; this requirement must be satisfied before merging.

**Context Used:** AGENTS.md ([source](https://github.com/illegalstudio/elephc/blob/main/AGENTS.md))

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

[Guikingone]

Addressed in 37225c6c3a. The runtime page listed __rt_php_float_to_int among the array/scalar entry points and said nothing about the capping sibling, so the reason a numeric string does not use the wrapping helper lived only in the code.

It now documents the rule table and why the split exists:

source	rule	helper	(int) of 1e19
a float VALUE	reduce modulo 2^64	__rt_php_float_to_int	-8446744073709551616
a numeric STRING	CAP at the integer range	__rt_php_float_to_int_cap	9223372036854775807

plus the reason both helpers check NaN and the infinities before converting: fcvtzs saturates by definition while cvttsd2si answers with the indefinite pattern, which is what made a bare conversion at a call site produce a per-target (int)NAN. All four values verified against host PHP 8.5.10.