develooper Front page | perl.perl5.porters | Postings from June 2017

Re: Behavior of bitwise ops on unencountered wide characters

Thread Previous
Graham Knop
June 9, 2017 16:51
Re: Behavior of bitwise ops on unencountered wide characters
Message ID:
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 <> 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 Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About