You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
remove pointless SVPV mortal alloc in S_strip_spaces()/prototype parser
Valid, parseable, and sane prototypes, are tiny in char len and often fit on 1 hand, most extreme cases in production would be 80 chars, because terminal length. Original commit referred to mitigating sloppy XS code with random white space. Majority of XS code will have perfect clean prototype strings. So not SV Alloc, PV Alloc, MEXTENDPUSH, memcpy(), and alot more free()s in scope _dec(), for clean strings. Even for dirty but parsable prototypes, they will be tiny in bytes. Therefore use a tiny stack buffer for dirty semi-hot path to remove overhead. Fuzzing, junk, abuse, can OOM die in newSV()/malloc() if needed, same as in prior version of the code. Use newSV(len) and POK_off, SV head is private to us, and a waste to bookkeep SVPV details. SAVEFREEPV() was not used, because previous code did mortal, and not SAVEFREEPV(), so keep using mortal. This can be changed if someone has rational to do it. 64 bytes was picked since its power of 2, and below 80, but not 16 or 32 bytes which is too small and C compiler would probably be leaving padding at the end of the array anyways. Going to 80 or 100, was discarded, to give breathing room on C stack to C compilers so on x86/x64 C compilers can emit U8 arithmitic with U8 constants to access various C autos, and the CC doesn't downgrade to U32 constants to access various local C auto. Worst case production Perl code for prototype length, is a URL argument template system on CPAN, and even urls, are unlikely to be longer than a desktop's URL bar or 80 char terminals. So 64 byte was picked. The struct provides type matching and length safety between S_strip_spaces() and its callers.
0 commit comments