develooper Front page | perl.perl5.porters | Postings from October 2003

Re: find_encoding("UTF-16BE")->encode("abc") does not NUL-terminate

Thread Previous | Thread Next
From:
Nick Ing-Simmons
Date:
October 8, 2003 03:20
Subject:
Re: find_encoding("UTF-16BE")->encode("abc") does not NUL-terminate
Message ID:
20031008101940.2598.5@llama.elixent.com
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


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About