Front page | perl.perl5.porters |
Postings from March 2021
On 31/3/21 14:40, Felipe Gasper wrote:
>
>> On Mar 31, 2021, at 2:44 AM, Salvador Fandiño <sfandino@gmail.com> wrote:
>>
>> On 31/3/21 0:30, Dan Book wrote:
>>> On Tue, Mar 30, 2021 at 4:48 PM Salvador Fandiño <sfandino@gmail.com <mailto:sfandino@gmail.com>> wrote:
>>> >> No solution is trivial or evident, and would have required
>>> investigation from the developer. So, I would expect most people did
>>> find about 2 and used it.
>>> >
>>> > A lot of XS modules use SvPV without checking SvUTF8. Alas.
>>> Yes, and almost all of them are broken!
>>> Technically yes, but practically is a different matter. Such modules (1) accidentally work correctly sometimes, and (2) work correctly always on ascii-only input. Fixing this wholesale, as in most instances of this bug, won't affect (2) but it will cause (1) to go from "sometimes broken" to "always broken".
>>
>> Well, some of those "sometimes broken" would also change to "fixed".
>>
>> Anyway, if you want a more conservative approach you can also make a version of SvPV (say SvPV_bad) that warns on first use and change the default typemaps to use it.
>
> I would love to take an approach like this, but I think it would create too many warnings in code that currently “happens” to work consistently.
You can make it warn just the first time it happens globally, of just
the first time if happens at some call point.
Another idea, probably inspired by your Sys::binmode module: we could
have a new strict category, i.e. "data_encoding":
use strict 'data_encoding';
syswrite(F, "\x{1234}"); # croaks!
xsub_using_default_SvPV_typemap("\x{1234}"); # croaks!
Thread Previous
|
Thread Next