[perl #128123] [JVM] failing test in S03-metaops/hyper.t after change from postfix:<++> to prefix:<++>

[Christian Bartolomaeus via RT]

On Wed May 11 00:51:48 2016, elizabeth wrote:
> Doesn’t this imply that prefix ++ on native ints is broken on the JVM.
> And thus, a lot of more got broken recently due to my changes??

That was my first thought, too. But this was the only place where rakudo-j got 
a hickup. Prefix++ works fine in different other places (and you changed some 
other postfix++ to prefix++ recently, IIRC). Probably this is another bug 
surfacing.

On Wed May 11 00:59:24 2016, elizabeth wrote:
> Reverted for JVM in d9b19da , but I think this warrants further
> research.

Thanks, Liz! I already tried to find the cause of the problem before I opened 
the ticket, but without success. However, we'll keep this ticket open until the 
problem has be resolved.

[perl #126529] [JVM] Buf.pm infix:<~> bug; breaks IO::Socket

[Christian Bartolomaeus via RT]

This works now (again):

$ perl6-j -e 'my Blob $a = "a".encode; my Blob $b = "b".encode; $a ~= $b; say 
$a.perl'
utf8.new(97,98)

I added this evaluation as a test to S03-operators/buf.t. I'm closing this 
ticket as 'resolved'.

[perl #126530] [JVM] Can't concatenate Bufs

[Christian Bartolomaeus via RT]

On Sat Oct 31 20:31:41 2015, coke wrote:
> See S03-operators/buf.t
> 
> Both of these fail:
> 
> ok $a ~ $b eq Buf.new(1, 2, 3, 1, 2, 3, 4), '~ and eq work on bufs';
> is-deeply Buf.new(1, 2, 3) ~ Buf.new(4, 5), Buf.new(1, 2, 3, 4, 5), '~
> concatenates';

These tests pass now (again). I'm closing this ticket as 'resolved'. (Tests are 
unfudged.)

Re: [perl #128161] Run time “SORRY!” when the range starts with whatever star (*...‘WAT’)

[Elizabeth Mattijsen]

My guess would be that there’s a string EVAL under the hood somewhere:

$ 6 'say "hello"; EVAL "foo"'
hello
===SORRY!=== Error while compiling /Users/liz/Github/rakudo.moar/EVAL_0
Undeclared routine:
foo used at line 1

Agree that the error could be considered LTA, as the “SORRY” indicates compile 
time, and it’s not from the user’s PoV.


Liz

> On 16 May 2016, at 18:44, Alex Jakimenko (via RT) 
>  wrote:
> 
> # New Ticket Created by  Alex Jakimenko 
> # Please include the string:  [perl #128161]
> # in the subject line of all future correspondence about this issue. 
> # https://rt.perl.org/Ticket/Display.html?id=128161 >
> 
> 
> Code:
> say ‘Hello’;
> *...‘WAT’
> 
> Result:
> Hello
> ===SORRY!===
> Method 'succ' not found for invocant of class 'Whatever'
> 
> 
> Well, I've always thought that ===SORRY!=== is compile time only.

Re: [perl #128159] [RFC] Disallow Invisible Terms and Operators for Security Reasons

[Elizabeth Mattijsen]

+1 from me.  Is there a unicode property that indicates invisibleness?


Liz
===
> On 16 May 2016, at 14:35, Zoffix Znet (via RT)  
> wrote:
> 
> # New Ticket Created by  Zoffix Znet 
> # Please include the string:  [perl #128159]
> # in the subject line of all future correspondence about this issue. 
> # https://rt.perl.org/Ticket/Display.html?id=128159 >
> 
> 
> Hi,
> 
> Currently, some invisible characters can be used as terms and operators. Some 
> of those are:
> 
>>  [⁠] U+2060 WORD JOINER [Cf]
><   [​] U+200B ZERO WIDTH SPACE [Cf]
>+   [⁡] U+2061 FUNCTION APPLICATION [Cf]
>-   [⁢] U+2062 INVISIBLE TIMES [Cf]
>.   [⁣] U+2063 INVISIBLE SEPARATOR [Cf]
>,   [] U+FEFF ZERO WIDTH NO-BREAK SPACE [Cf]
> 
> This allows for malicious and invisible action at a distance. For example, in 
> one module I can define this invisible operator:
> 
>sub prefix:<⁣> is tighter(:) is export {spurt 'DEBUG.txt', $^a, 
> :append};
> 
> It uses U+2063 invisible separator. Now, in code that `use`s this module, I'm 
> now able to silently
> steal data, like say this:
> 
>use SomethingInnocent;
>⁣my $credit_card = '---'; # pretend this is coming in from 
> DB
> 
> By prefixing the `my` with U+2063 invisible separator, I'm silently siphoning 
> the data assigned to $credit_card into a secret file. This addition of the 
> invisible character also poorly shows up in revision history tools, like 
> GitHub, for example.
> 
> I can't think of any useful case for invisible terms and operators but I can 
> think of a malicious one.
> 
> Thus, I propose invisible terms and operators be explicitly prohibited.