Joseph Ferano
5810fa286f
(slice s 2 1) has length 2 - 1 - 2 = -1. flan_bytes_to_i64 and flan_bytes_to_f64 both wrote their clamp as (size_t)n < sizeof buf - 1, and (size_t)(-1) is 18446744073709551615, which is not less than 511 -- so k took the cap and the memcpy copied 63 or 511 bytes out of a five-byte string constant. ASan calls it a global-buffer-overflow in flan_bytes_to_i64; the regression case is in test_sanitize. Every other (ptr, len) entry point in the runtime already guarded the negative case -- flan_write_stdout tests n > 0, flan_escape_bytes and flan_dev_emit both fold a negative length to zero -- so this was two exceptions rather than a missing convention. A checked build traps on the reversed slice before reaching either, which is why it took an --no-bounds-checks run to show. Also clamps the three snprintf shims that publish scratch as a slice. snprintf returns what it would have written, not what it did, so a format that overran the 64-byte buffer would hand out a length past its end. No format here can: %g is 13 characters and %lld is 20. Found by reading, and the sweep could not have found it -- nothing in forty programs prints a number that long.
