[p5.js 2.0+ Bug Report]: int() truncates numbers to 32 bits, disagreeing with the same value passed as a string

Most appropriate sub-area of p5.js?

Utilities

p5.js version

2.x main (4b096e2)

Actual vs expected behavior

The numeric path of int() uses n | 0, which wraps at 32 bits, while the string path uses parseInt, which does not. The same value converts differently depending on its type, and large values silently go negative:

int(4000000000)   // -294967296
int('4000000000') // 4000000000
int(2**31)        // -2147483648
int(1e10)         // 1410065408

The reference only documents decimal removal ("If the original value has decimals, as in -34.56, they're removed to produce an integer such as -34"); nothing licenses wraparound. Timestamps (Date.now() is already ~1.7e12) and other large values are realistic inputs.

Steps to reproduce

Outputs above are from executed runs against main.

Note

I have a one-line fix ready (Math.trunc(n)) with two unit tests (no 32-bit truncation, number/string agreement), mutation-tested against main; int(-34.56) still returns -34 and the existing byte() tests that route through int() still pass. One behavior note: int(NaN) changes from 0 to NaN, which matches the documented "If a value can't be converted to a number... NaN will be returned"; no existing test covers it. Filing for approval first per the contributing guide; will open the PR once approved.

Start at the numeric conversion path in int() and compare it with the string path described in the report. Add coverage for large numbers and number/string agreement, then run the existing byte() tests and the new unit tests; done means decimal removal still works without 32-bit wraparound and the documented invalid-value behavior is preserved.