Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

[perl #39044] Problem with :slurpy, :slurpy :named, :flat :named

5 views
Skip to first unread message

Patrick R . Michaud

unread,
May 1, 2006, 4:12:30 PM5/1/06
to bugs-bi...@rt.perl.org
# New Ticket Created by Patrick R. Michaud
# Please include the string: [perl #39044]
# in the subject line of all future correspondence about this issue.
# <URL: https://rt.perl.org/rt3/Ticket/Display.html?id=39044 >


---
osname= linux
osvers= 2.6.12
arch= x86_64-linux-thread-multi
cc= cc
---
Flags:
category=core
severity=medium
ack=no
---
Several have asked me to go ahead and file an RT report
for the failing test in t/op/calling.t (currently test #91)
so that people aren't left wondering why it fails.

Currently Parrot has a variety of troubles with :slurpy and
:slurpy :named both appearing in parameter lists. In
particular, given a function such as

.sub foo
.param pmc array :slurpy
.param pmc hash :slurpy :named
...


The following call to foo will lose one of the values of $P0:

.sub main
$P0 = new .Hash
$P0['a'] = 11
$P0['b'] = 22
$P0['c'] = 33
foo(0, 1, $P0 :flat :named)

That is, when sub foo is executed, "hash" will appear to have only
two entries in it instead of three. (This is test #91 in t/op/calling.t.)

Surprisingly, it seems to work properly if a named argument is explicitly
given in the argument list:

.sub main
$P0 = new .Hash
$P0['a'] = 11
$P0['b'] = 22
$P0['c'] = 33
foo(0, 1, 'XXX'=>0, $P0 :flat :named)

That is, when sub foo is executed here, "hash" correctly has
four entries in it. This is test #92 in t/op/calling.t (and
for the moment I'm using this approach in PGE as a workaround
for the bug).

Pm

---
Summary of my parrot 0.4.3 (r12477) configuration:
configdate='Mon May 1 14:06:21 2006'
Platform:
osname=linux, archname=x86_64-linux-thread-multi
jitcapable=0, jitarchname=nojit,
jitosname=linux, jitcpuarch=x86_64
execcapable=0
perl=/usr/bin/perl
Compiler:
cc='cc', ccflags='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGING -pipe -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -fPIC -I /usr/include',
Linker and Libraries:
ld='cc', ldflags=' -L/usr/local/lib64',
cc_ldflags='',
libs='-lm -ldl -lcrypt -lpthread -lrt -lreadline'
Dynamic Linking:
share_ext='.so', ld_share_flags='-shared -L/usr/local/lib64 -fPIC',
load_ext='.so', ld_load_flags='-shared -L/usr/local/lib64 -fPIC'
Types:
iv=long, intvalsize=8, intsize=4, opcode_t=long, opcode_t_size=8,
ptrsize=8, ptr_alignment=1 byteorder=12345678,
nv=double, numvalsize=8, doublesize=8

---
Environment:
HOME LANG LANGUAGE LD_LIBRARY_PATH LOGDIR PATH SHELL

Leopold Toetsch

unread,
May 11, 2006, 10:51:24 AM5/11/06
to perl6-i...@perl.org, bugs-bi...@netlabs.develooper.com
Patrick R.Michaud (via RT) wrote:

> Currently Parrot has a variety of troubles with :slurpy and
> :slurpy :named both appearing in parameter lists. In
> particular, given a function such as
>
> .sub foo
> .param pmc array :slurpy
> .param pmc hash :slurpy :named

Fixed. Thanks for the test.
eo

0 new messages