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:
Jan Dubois
Date:
October 8, 2003 09:19
Subject:
Re: find_encoding("UTF-16BE")->encode("abc") does not NUL-terminate
Message ID:
oid8ov4ijpmvedsgru3ft4c2lvtg5a26cg@4ax.com
On Wed, 08 Oct 2003 11:19:40 +0100, "Nick Ing-Simmons"
<nick.ing-simmons@elixent.com> wrote:

>Gisle Aas <gisle@ActiveState.com> writes:
>
>>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.

Wouldn't this be really inconvenient for any XS glue that calls out to C
code.  You couldn't pass SvPVX() or SvPV_nolen() to a function expecting a
char* but would always have to make a copy into a malloc()ed buffer.  I
bet there are a lot of modules on CPAN that still call SvPV(), disregard
the returned len and just pass the char* on to an external library.

The Perl code doesn't know if the PV contains a string or arbitrary binary
data.  Therefore I think the safest thing would be to always provide the
trailing NUL, but not rely on it being there.

I guess Parrot can provide a mechanism to automatically copy strings when
calling external functions, based on some kind of IDL description of the
external function.

Cheers,
-Jan

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