On Thu May 26 21:38:50 2016, sprout wrote:
On Thu May 26 18:52:05 2016, [email protected] 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 <[email protected]>
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:

$ 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 '$$$', but 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 ‘\$$$’.

Also, those ‘Can't modify’ messages cite the wrong op (list/scalar assignment instead of vec).


Father Chrysostomos

via perlbug: queue: perl5 status: open

Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 3 of 4 | next ›
Discussion Overview
groupperl5-porters @
postedMay 27, '16 at 1:52a
activeMay 28, '16 at 12:55a

1 user in discussion

Father Chrysostomos via RT: 4 posts



site design / logo © 2023 Grokbase