On Thu May 26 21:58:20 2016, sprout wrote:
vec’s first argument must be a valid lvalue, so the prototype is
wrong:
$ perl -we '(vec $_+1,0,1)=0'
Can't modify addition (+) in list assignment at -e line 1, at EOF
Execution of -e aborted due to compilation errors.
$ perl -we 'vec($_+1,0,1)=0'
Can't modify addition (+) in scalar assignment at -e line 1, at EOF
Execution of -e aborted due to compilation errors.
It’s prototype currently is effectively ‘\[$@%*]$$’, but it should
probably be ‘\$$$’.
It’s more complicated than that. vec does accept $_+1 if vec itself is in rvalue context, so its actual behaviour cannot be represented perfectly with a prototype.
Also, those ‘Can't modify’ messages cite the wrong op (list/scalar
assignment instead of vec).
On Thu May 26 21:38:50 2016, sprout wrote:
$ perl -we '(vec%0,0,1)=0'
Use of uninitialized value within %0 in vec at -e line 1.
Can't coerce HASH to string in aassign at -e line 1.
That output is nonsensical.
Thank you for finding one. :-)
A related issue is that prototype("CORE::vec") returns '$$$', butOn Thu May 26 18:52:05 2016, dcollinsn@gmail.com wrote:
A git bisect was performed and
reported the following, which appears to be when the assert was
initially added.
217f6fa330a187be32a68556507e3165b8747f55 is the first bad commit
commit 217f6fa330a187be32a68556507e3165b8747f55
Author: Father Chrysostomos <sprout@cpan.org>
Date: Fri Jul 19 08:51:47 2013 -0700
sv.c: Assert that sv_[ivp]v are not passed aggregates
The lack of assertions can hide bugs. See 32a609747bffb for
instance
That assertion was added specifically to find bugs like this:A git bisect was performed and
reported the following, which appears to be when the assert was
initially added.
217f6fa330a187be32a68556507e3165b8747f55 is the first bad commit
commit 217f6fa330a187be32a68556507e3165b8747f55
Author: Father Chrysostomos <sprout@cpan.org>
Date: Fri Jul 19 08:51:47 2013 -0700
sv.c: Assert that sv_[ivp]v are not passed aggregates
The lack of assertions can hide bugs. See 32a609747bffb for
instance
$ perl -we '(vec%0,0,1)=0'
Use of uninitialized value within %0 in vec at -e line 1.
Can't coerce HASH to string in aassign at -e line 1.
That output is nonsensical.
Thank you for finding one. :-)
vec’s first argument must be a valid lvalue, so the prototype is
wrong:
$ perl -we '(vec $_+1,0,1)=0'
Can't modify addition (+) in list assignment at -e line 1, at EOF
Execution of -e aborted due to compilation errors.
$ perl -we 'vec($_+1,0,1)=0'
Can't modify addition (+) in scalar assignment at -e line 1, at EOF
Execution of -e aborted due to compilation errors.
It’s prototype currently is effectively ‘\[$@%*]$$’, but it should
probably be ‘\$$$’.
It’s more complicated than that. vec does accept $_+1 if vec itself is in rvalue context, so its actual behaviour cannot be represented perfectly with a prototype.
Also, those ‘Can't modify’ messages cite the wrong op (list/scalar
assignment instead of vec).
$ perl -we 'vec(%a,0,1)=0'
Can't modify hash dereference in scalar assignment at -e line 1, at EOF
Execution of -e aborted due to compilation errors.
$ perl -we '(vec%a,0,1)=0'
Name "main::a" used only once: possible typo at -e line 1.
Use of uninitialized value within %a in vec at -e line 1.
Can't coerce HASH to string in aassign at -e line 1.
vec is not the only problematic operator.
$ ./perl -we '(substr %a,0,1)=0'
Name "main::a" used only once: possible typo at -e line 1.
Can't coerce HASH to string in list assignment at -e line 1.
$ ./perl -we 'substr(%a,0,1)=0'
Can't modify hash dereference in scalar assignment at -e line 1, at EOF
Execution of -e aborted due to compilation errors.
The second one dies at compile time; the first one does the wrong thing at run time. Same problem.
--
Father Chrysostomos
---
via perlbug: queue: perl5 status: open
https://rt.perl.org/Ticket/Display.html?id=128260