fix: correct int/int32_t pointer mismatches for -Wincompatible-pointer-types - #1657
Conversation
…r-types Six call sites pass an int* where int32_t* is expected (or the reverse) in find_line_num, js_parseInt, remainingElementsCount_add, js_promise_all_resolve_element, and js_atomics_notify. Both types are 32-bit signed everywhere this project targets, so there is no behavioral change, but on any target where stdint.h defines int32_t as long int (ESP-IDF/ESP32 since v5.0), GCC 14+ treats the mismatch as a hard -Wincompatible-pointer-types error and the file fails to build. Retype the five local variables to match the callee signature already used at every other call site.
|
Drop the plan |
|
ping @SomSamantray |
316e14e to
335ffae
Compare
|
Dropped the plan doc from the branch (rebased it out) and pushed — the PR is now scoped to the single |
Done — rebased the branch to drop that commit entirely. The PR is now scoped to the single |
Responded — see the comment above. Plan doc dropped, fix re-verified (clean build, |
On any target whose
stdint.hdefinesint32_taslong intrather thanint— every ESP-IDF/ESP32 chip since v5.0 —quickjs.cfails to compile under GCC 14+, because-Wincompatible-pointer-typesis now an error by default there. Six call sites across five local variables pass anint *where anint32_t *is expected, or the reverse.Both types are 32-bit signed on every platform this project targets, so there's no behavioral difference — this retypes the five local variables (
find_line_num'sv,js_parseInt'sradix,remainingElementsCount_add'sremainingElementsCount,js_promise_all_resolve_element'sindex, andjs_atomics_notify'scount) to match the callee signature each is already used against everywhere else in the file. No callee signatures changed.Verified locally without ESP32 hardware or a GCC 14 install: shimming
int32_tto a distinct-but-same-width type and compiling withclang -std=gnu11 -Werror=incompatible-pointer-typesreproduces the exact 6 errors at the exact reported lines before the fix, and compiles clean after. Also confirmed the normal (unshimmed) build still succeeds,api-testpasses, and manually exercisedparseInt('ff', 16)andAtomics.notifyto confirm unchanged behavior.Fixes #1624