Front page | perl.perl5.porters |
Postings from June 2017
Re: Behavior of bitwise ops on unencountered wide characters
Thread Previous
From:
Graham Knop
Date:
June 9, 2017 16:51
Subject:
Re: Behavior of bitwise ops on unencountered wide characters
Message ID:
CAM=m89EVUstvZnqF2yaGkmARZN7iAHS2m_n12T1r7J39LQhxGA@mail.gmail.com
I actually made a mistake in my initial email. What I'm using to
check the flags is $var & "". The result of that will always be "" or
0. Using ^ for number detection is possible, but runs into issues
with wide characters.
I think allowing & to work on strings with wide characters where the
wide characters don't end up in the output is pretty reasonable. For
^ and |, it is a bit strange and I wouldn't mind it being deprecated.
The use case is definitely a bit dodgy, but there doesn't seem to be
any reason to break it. We have already added a way to disambiguate
the behavior of bitwise ops with the 'bitwise' feature.
On Fri, Jun 9, 2017 at 6:40 PM, Abigail <abigail@abigail.be> wrote:
> On Fri, Jun 09, 2017 at 09:24:53AM -0600, Karl Williamson wrote:
>> On 06/09/2017 03:17 AM, Graham Knop wrote:
>>> Bitwise operations on wide characters have been deprecated since 5.24,
>>> and issue a warning. This has been changed to be fatal in blead.
>>> However, the change that is currently in place will die in places that
>>> previously didn't get the deprecation warning at all. If one of the
>>> strings in a bitwise operation is shorter than where the wide
>>> characters exist in the other, no warning would be issued. The
>>> resulting string would either stop at the length of the shorter string
>>> for &, or have the remaining characters copied unmodified from the
>>> longer string for ^ and |.
>>>
>>> For example:
>>> perl -we' my $f = "" & "\x{ABCD}" '
>>>
>>> This will not warn on 5.26, but is fatal in blead. The change was
>>> introduced in 08b6664b858b8fd4b5c0c27542763337b6d78e46.
>>>
>>> This breaks code that I'm using, including newer versions of JSON::PP.
>>> The reason I'm using this is admittedly an abuse of the bitwise ops
>>> for number detection. The result of ($var ^ "") can tell you the
>>> status of the internal flags for a if value is a valid number, which
>>> is needed for serialization. The alternative is using B to examine
>>> the flags, which is significantly slower.
>>>
>>> Doing operations like this doesn't run into the problems motivating
>>> the removal of bitwise ops on wide characters, so I would vote for
>>> restoring support for it. If that is not an option, there at least
>>> needs to be a release cycle with a deprecation warning for this.
>>>
>>
>> I think it is correct to allow the & case where the non-downgradable
>> characters don't figure in the output.
>>
>> I agree that blead needs to change to handle the | and ^ cases so the
>> result of the operation is unchanged from previous releases. I don't
>> know if this usage should be deprecated or not. I look forward to
>> seeing discussion concerning that.
>
>
> I think it should be deprecated. Allowing some characters in a string
> as an argument to a bitwise operator to exceed 0xFF, but not allowing
> others, the decisions which are and which aren't to be determined by the
> length of the other argument, and the operator just makes it harder to
> explain the language.
>
> I also think the use case ("it can tell you the status of the internal
> flags") a bit dodgy. Does p5p want to commit to keeping '$var ^ ""' tell
> you the status of the internal flags? If not, then a future change may
> break the $var ^ "" trick in a different way.
>
>
>
> Abigail
Thread Previous