Re: [perl #54920] [PATCH] Compiling pcc.c on Solaris10-x86

2008-05-29 Thread Andrew Johnson
tiger% ./parrot -t t/dynoplibs/myops_3.pir 0 print "neither here\n" neither here 2 hcf Segmentation fault When run under a debugger, it looks like this: (dbx) run -t t/dynoplibs/myops_3.pir Running: parrot -t t/dynoplibs/myops_3.pir (process id 15185) Reading myops_ops.so 0 print

Re: [perl #56052] Storable issue

2008-06-19 Thread Andrew Johnson
On Thursday 19 June 2008 12:13:40 Mark Glines via RT wrote: > On Wed Jun 18 10:57:05 2008, [EMAIL PROTECTED] wrote: > > On Solaris10 with sparc, during the make process I get this: > > > > perl /home/phoebus3/ANJ/work/parrot/tools/build/pmc2c.pl --c > >subproxy.pmc > > Cannot restore overloadin

Re: [perl #56006] Test failures on Solaris10-x86

2008-06-20 Thread Andrew Johnson
On Thursday 19 June 2008 20:33:31 James Keenan via RT wrote: > > In Perl 5, what is the value for $^O on your system? (I'd like to have > it for doing a SKIP on the TODO passing test above.) perses% perl -e 'print "$^O\n";' solaris - Andrew -- Talk is cheap. Show me the code. -- Linus Torvalds

Re: [perl #56110] [PATCH] Warnings on Solaris

2008-06-20 Thread Andrew Johnson
On Thursday 19 June 2008 15:33:14 Parrot via RT wrote: > "src/packfile.c", line 351: warning: argument #1 is incompatible with > prototype: >         prototype: pointer to char : "/usr/include/sys/mman.h", line 161 >         argument : pointer to long > "src/packfile.c", line 878: warning: argument

Re: [perl #56110] [PATCH] Warnings on Solaris

2008-06-23 Thread Andrew Johnson
On Monday 23 June 2008 09:08:07 NotFound wrote: > Here is the patch. It avoids the warning both in C and C++ with gcc. Works fine for me, no warning. It might be worth adding a comment into parrot.h to clarify that PARROT_const_cast should *only* be used for c/v qualifier changes, and that addi

Re: [perl #56110] [PATCH] Warnings on Solaris

2008-07-09 Thread Andrew Johnson
On Tuesday 08 July 2008 17:55:42 NotFound wrote: > On Mon, Jun 23, 2008 at 4:37 PM, Andrew Johnson <[EMAIL PROTECTED]> wrote: > >> Here is the patch. It avoids the warning both in C and C++ with gcc. > > > > Works fine for me, no warning. > > It might be wor

Re: Warnings on Solaris, Pmc2c usage/design bug

2008-07-10 Thread Andrew Johnson
On Wednesday 09 July 2008 12:03:19 chromatic wrote: > On Wednesday 09 July 2008 08:27:35 Andrew Johnson wrote: > > Confirmed, those warnings have gone. I'm still getting loads of > > "warning: statement not reached" but I'll work out how to suppress those >

Re: Warnings on Solaris, Pmc2c usage/design bug

2008-07-10 Thread Andrew Johnson
On Thursday 10 July 2008 13:12:41 NotFound wrote: > On Thu, Jul 10, 2008 at 7:44 PM, Andrew Johnson <[EMAIL PROTECTED]> wrote: > >> Except the src/pmc/nci.pmc line 486, there is not such line in the > >> file, and I'm unable to locate the problem. > > > >

Re: Warnings on Solaris, Pmc2c usage/design bug

2008-07-10 Thread Andrew Johnson
On Thursday 10 July 2008 10:44:51 NotFound wrote: > On Wed, Jul 9, 2008 at 9:33 PM, Andrew Johnson <[EMAIL PROTECTED]> wrote: > > The other warnings I get on Solaris are just these: > > > > "src/stm/backend.c", line 969: warning: statement not reached >

[perl #57900] solaris hints no longer work

2008-08-14 Thread Andrew Johnson via RT
On Wed Aug 13 10:41:22 2008, [EMAIL PROTECTED] wrote: > > Does this patch help? Almost, you just missed the executable itself (-o arg). This patch works for me. - Andrew Index: solaris.pm === --- solaris.pm (revision 30211) +++ so

[perl #56448] [BUG] tailcalls cause segfault when invoked from C

2008-06-30 Thread Andrew Johnson via RT
The segfault occurs inside clone_key_arg() inside src/inter_call.c (at line 871), which has the following leading POD description (committed by chromatic who also committed most of the implementation): Replaces any src registers by their values (done inside clone). This needs a test for tailcalls

[perl #56636] [BUG] [PATCH] segfault from sort if comparison is always 1

2008-07-06 Thread Andrew Johnson via RT
On Sun Jul 06 11:03:37 2008, japhb wrote: > > Better yet, we should replace the inherently insecure quicksort > algorithm (insecure in the "vulnerable to algorithmic attack" sense) > with a more secure mergesort like perl5 uses. IIRC, perl5's mergesort > is also carefully crafted to be as sensibl