fix: Replace sprintf with snprintf in vendored FlatCC pstdint self-test

[orbisai0security]

Summary

This PR replaces several sprintf() calls with snprintf() in the vendored FlatCC pstdint.h portability self-test code.

Impact

This is not claimed as an exploitable memory-safety vulnerability in arrow-nanoarrow.

The affected buffers are fixed-size 256-byte local arrays, and the formatted values are fixed test constants rather than user-controlled input. In practice, the formatted integer strings are far smaller than the available buffer size.

Rationale

The change is intended as a small defensive cleanup:

• avoids unbounded formatting APIs in vendored code
• reduces static-analysis noise around sprintf()
• keeps the code aligned with safer C formatting practices

Since this code is vendored from FlatCC, I will also file the same cleanup upstream so the change can be considered at the source project.

Changes

• thirdparty/flatcc/include/flatcc/portable/pstdint.h

Testing

Existing tests should continue to pass; this change only bounds the destination size used for formatting and does not alter the expected formatted output.

Verification

• Build passes
• Scanner re-scan confirms fix
• LLM code review passed

---

Automated security fix by OrbisAI Security

[paleolimbot]

Happy to merge, but this should be filed with flatcc and is not a real issue with memory safety (the buffers are not user-supplied and the size is a statically checkable 256 bytes in each case).

[orbisai0security]

Thanks, agreed. I overstated the memory-safety impact here.

Given the actual context, these are fixed-format values written into 256-byte local buffers, so I agree this is not a practical memory-safety issue in arrow-nanoarrow. I’ll reframe this as a low-risk cleanup / defensive hygiene change rather than a vulnerability.

Since this is vendored FlatCC code, I’ll also file the same cleanup upstream with FlatCC so the change can flow from the source project.

I’ll update the PR title/description accordingly.

[amoeba]

Since there isn't a real security risk, I think the benefit of keeping the vendored copy identical with upstream would outweigh the downside of patching this.