Gisle Aas <gisle@ActiveState.com> writes: >> >> The SvLEN(sv) == 0 case (SvPV is owned by someone else) is made considerably >> less useful if code expects terminating '\0' - the alien SvPV may not >> have that property, but doing a new malloc and a mega-byte copy just to >> add the '\0' is a pain. > >This is a good point. Is SvLEN(sv) == 0 the hack used much? Well I am a fan - it is used in PerlIO and also the "shared hash key" stuff. (In latter case the NUL is the the shared thing so it is not an issue.) So I think its use is growing... I am almost certainly responsible for encoding not doing the NUL thing. > >But, this also make perl really unsafe. You will easily get a >segfault if you call any system call builtins with that string. Perl >could be made to do the copy if such an SV was passed to such a >function or we could add a flag bit (if there are any left) that can >be set when you are able to quaranteee NUL-termination for strings >with SvLEN(sv) == 0. > >> There are very few spots in the core which _need_ the NUL > >I think there are quite a few, but they don't show because there is >almost never any strings that are missing it. I seem to recall a number of spots that look like they do have done something akin to SvGROW(sv,SvCUR(sv)+1) before they do it (but this may just be wishful thinking on my part). >Do you think we should >redefine the invariant to not need the terminating NUL and fix all >code that depend it this? Personally yes - but that may be Perl6 (Parrot) thing.Thread Previous | Thread Next