@{ ... } dereferences a reference into an array. In this case, you're trying to coerce the return value of $_ =~ m// into being an array. That actually attempts to create a symbolic reference, creating a variable named @1.

$#{ ... } tries to find the highest index of @1.

If you turn on use strict; and use warnings; you'll get all sorts of clues.

In that case

$#{@1}
[download]


would die in the same way. It does not.

$#{@1}
[download]

would die in the same way. It does not.

No, it wouldn't, as it doesn't use a symbolic reference...

If you take the time to dump or peek at @1, you'll see that it exists as empty array...as do all @NUM I tested.

My guess was, that @1 exists as a side effect of $1 beeing a default-variable and the "multi-type" nature of perl variables. I'd love to be corrected/educated on this rather blunt assumption I wasn't able to backup with my first dive into Devel::Peek and the like.

regards,
tomte

---

Hlade's Law:

If you have a difficult task, give it to a lazy person --
they will find an easier way to do it.

Actually, it does die, but only in the debugger.

% perl -d -e '$#{@1}'
Default die handler restored.

Loading DB routines from perl5db.pl version 1.07
Editor support available.

Enter h or `h h' for help, or `man perldebug' for more help.

main::(-e:1):    $#{@1}
  DB<1> c
Bizarre copy of ARRAY in leave at -e line 1.
Debugged program terminated.
[download]

Without the debugger, it works fine.

This error message is created in sv.c, in the function Perl_sv_setsv. This function copies a scalar value from one location to another. "Bizarre copy of ARRAY in leave" means that an opcode called "leave" tried to copy an array to a scalar, should be impossible. "leave" is the opcode for leaving a block of code. Why this happened, I cannot figure out.

correction: in that case

$#{@{"1"}}
[download]

would die in the same way. This however, does work:

@a=@{//};$#a
[download]

Why?

Seems to me a bug report is in order.

Liz

Strange indeed.

And $#{$x=@{//}}; does not fail.