develooper Front page | perl.perl5.porters | Postings from March 2021

Re: Perl 7: Fix string leaks?

Thread Previous | Thread Next
From:
=?UTF-8?Q?Salvador_Fandi=c3=b1o?=
Date:
March 30, 2021 14:28
Subject:
Re: Perl 7: Fix string leaks?
Message ID:
6a40fe6f-ad20-5e67-9859-730976e771a9@gmail.com
On 30/3/21 12:45, Felipe Gasper wrote:

> The fix here is to switch the typemap to SvPVbyte so that identical Perl strings will yield identical C representation.

Any XS code that is using SvPV to convert SVs to char* is already broken.

IMO, the default typemap could be changed right now.

> The same bug exists if you mkdir($str_a) and mkdir($str_b). See Sys::Binmode for a CPAN fix. I hope to convince enough folks here to bring that into core eventually.

If I understand what Sys::Binmode does correctly, it just ensures that 
any string going to be used in a system call is first downgraded to
bytes, and so, effectively encoding it as latin1 or whatever it is the 
default code page in Windows.

I don't think that really tackles the real problem. It fixes some issues 
but it is not what Perl really needs in the long run.

I don't see as acceptable either to ask the programmer to do the 
encoding/decoding explicitly in his code every time before/after some 
data crosses the OS interface.

Other languages (Python, Ruby) try to guess the encoding from the 
environment in Linux/UNIX/OS X or use the default encoding, UTF-16, on 
Windows.

That also has their issues as OSs don't check the validity of the given 
strings and so file systems can contain invalid sequences and Perl 
should be able to handle those anyway. But encodings like WTF8 can be 
used to overcome that.


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