fix: fix memory bugs and last-char truncation in deHTMLxs XS

[toddr-bot]

What

Fix three bugs in the deHTMLxs XS extension: memory leak, input truncation, and unsafe memory operations.

Why

doit() overwrote the last character of input with \0 before HTML stripping — silently losing one byte of content on every call. It also leaked an intermediate SV via newSVpv + sv_setsv (the temporary was never freed), and used C malloc/free instead of Perl's Newx/Safefree memory API (bypassing Perl's memory debugging and tracking). Additionally, doit() had no guard against empty strings — calling it with size==0 would write to raw[-1] (buffer underflow).

How

• Truncation: Removed *(raw + size - 1) = '\0' — Perl SVs from SvPV are already null-terminated at raw[size], making this destructive overwrite unnecessary.
• Memory leak: Replaced newSVpv + sv_setsv with sv_setpv, which sets the value directly without creating a temporary SV.
• Memory API: Replaced malloc/free with Newx/Safefree. Also replaced deprecated Newz with Newxz in new().
• Empty string: Added size == 0 guard before buffer operations.
• isit() mutation: Removed sv_catpv(text, &mynull) hack that unnecessarily touched the input SV.

Testing

All 182 tests pass. Golden .deHTMLxs files regenerated — 5 files grew by exactly 1 byte each (the previously truncated character).

🤖 Generated with Claude Code

---

Quality Report

Changes: 6 files changed, 15 insertions(+), 34 deletions(-)

Code scan: clean

Tests: passed (OK)

Branch hygiene: clean

Generated by Kōan post-mission quality pipeline

[toddr-bot]

CPAN Testers Evidence

I analyzed the CPAN Testers failure reports for v2.86 (API data). The results confirm this PR fixes the root cause of all 45 FAIL reports.

Summary

• 1293 PASS (Linux, FreeBSD, macOS)
• 45 FAIL — all on MSWin32, all failing the same 3 tests: html.4, html.5, html.8
• 67 UNKNOWN — build failures from parallel make race (already fixed by Unbreak builds with parallel make at manifypods-razor #10)

Root Cause Chain

1. The truncation bug (*(raw + size - 1) = '\0') in doit() drops the final \n from CRLF files, leaving a bare \r at the end of the XS output
2. The golden .deHTMLxs files correctly encode this truncated output (ending with bare \r)
3. On Windows, CPAN clients extract tarballs via Archive::Tar in text mode, converting \n → \r\n
4. This turns the input's \r\n → \r\r\n, but the golden file's bare trailing \r is unaffected
5. After truncation of the expanded input, output ends with \r\r, but golden file ends with \r → mismatch

Why only html.4, html.5, html.8

These three input files end with </html>\r\n — the truncation creates a trailing bare \r that survives outside tags. The passing CRLF files (html.6, html.7) end with </html> (no trailing newline), so the truncation only removes the tag's closing >, which is swallowed by tag processing.

Why this PR fixes it

With truncation removed, the golden files end with proper \r\n instead of bare \r. On Windows, text-mode extraction consistently converts all \r\n �� \r\r\n in both input and expected files. The XS output from the expanded input matches the expanded expected file at every position, including the end.

🤖 Analysis by Kōan