Front page | perl.perl5.porters |
Postings from July 2001
Re: perl@10825 on UTS
Thread Previous
|
Thread Next
From:
Nicholas Clark
Date:
July 1, 2001 06:35
Subject:
Re: perl@10825 on UTS
Message ID:
20010701143518.R59620@plum.flirble.org
On Sat, Jun 30, 2001 at 06:22:48PM -0700, Hal Morris wrote:
> >
> > On Sat, Jun 30, 2001 at 10:31:50AM -0700, Hal Morris wrote:
> >
> > > not ok 10 # a5050081a5020082a5000084a530a48100faa5000081a4bd0084a54000ffa4ff00ffa57fa5840080a4800080a51487ffffffffffdb19caefe8e1eeeea0c2e1e3e8ede1ee6e
> >
> > > not ok 22 # 0
>
>
> With the changes to pp_pack.c, got the following;
>
> not ok 10 # 6205008162020082620000846230a48100fa62000081a4bd0084624000ffa4ff00ff627f61840080a4800080621487ffffffffffdb19caefe8e1eeeea0c2e1e3e8ede1ee6e
It's still doing type bytes instead of 1. What about this?
--- pp_pack.c~ Sun Jul 1 00:28:06 2001
+++ pp_pack.c Sun Jul 1 14:25:27 2001
@@ -1633,7 +1633,8 @@
UV auv = U_V(adouble);
do {
- *--in = (auv & 0x7f) | 0x80;
+ --in;
+ *in = (auv & 0x7f) | 0x80;
auv >>= 7;
} while (auv);
buf[sizeof(buf) - 1] &= 0x7f; /* clear continue bit */
Patch ought to apply on either the original or with the other patch.
[and I don't think it will matter whether those pointers are char or
unsigned char]
> I applied the changes to perl.h given in the last message also, but
> all that changed was the nature of these two failures in pack.t.
Thanks. Ah. Hmm.
Nicholas Clark
Thread Previous
|
Thread Next