Regarding HTTP_Request bug #10790

I was wondering what the status on this is.  It's biting us
right now
and I'd like to see a fix go through the proper channels, as
opposed
to hacking it locally.

According to http://bugs.php.
net/bug.php?id=39062
the following diff should ensure that this bug is squashed,
even if
the PHP folks decide to change the behaviour of crc32()
again:

1374c1374
<             if ($crcReal != $crcStored[1]) {
---
>             if (dechex($crcReal) !=
dechex($crcStored[1])) {
1390c1390
<         } elseif ($dataCrc != crc32($unpacked)) {
---
>         } elseif (dechex($dataCrc) !=
dechex(crc32($unpacked))) {


-- 
Bill Moran
Collaborative Fusion Inc.
http:/
/people.collaborativefusion.com/~wmoran/

wmorancollaborativefusion.com
Phone: 412-422-3463x4023

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

Hi,

Bill Moran wrote:
> I was wondering what the status on this is.  It's
biting us right now
> and I'd like to see a fix go through the proper
channels, as opposed
> to hacking it locally.
> 
> According to http://bugs.php.
net/bug.php?id=39062
> the following diff should ensure that this bug is
squashed, even if
> the PHP folks decide to change the behaviour of crc32()
again:
> 
> 1374c1374
> <             if ($crcReal != $crcStored[1]) {
> ---
>>             if (dechex($crcReal) !=
dechex($crcStored[1])) {
> 1390c1390
> <         } elseif ($dataCrc != crc32($unpacked)) {
> ---
>>         } elseif (dechex($dataCrc) !=
dechex(crc32($unpacked))) {


Have you tested the fix in question? I don't have a 64-bit
box around, so will 
have to rely on someone else testing it.

And yes, I'm going to do a bugfix release sometime soon, but
will need to fix 
#10605 also and revisit the gzip vs. mb_*() changes done
sometime ago.

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

In response to Alexey Borzov <borz_offcs.msu.su>:

> Hi,
> 
> Bill Moran wrote:
> > I was wondering what the status on this is.  It's
biting us right now
> > and I'd like to see a fix go through the proper
channels, as opposed
> > to hacking it locally.
> > 
> > According to http://bugs.php.
net/bug.php?id=39062
> > the following diff should ensure that this bug is
squashed, even if
> > the PHP folks decide to change the behaviour of
crc32() again:
> > 
> > 1374c1374
> > <             if ($crcReal != $crcStored[1]) {
> > ---
> >>             if (dechex($crcReal) !=
dechex($crcStored[1])) {
> > 1390c1390
> > <         } elseif ($dataCrc !=
crc32($unpacked)) {
> > ---
> >>         } elseif (dechex($dataCrc) !=
dechex(crc32($unpacked))) {
> 
> 
> Have you tested the fix in question? I don't have a
64-bit box around, so will 
> have to rely on someone else testing it.

funny you should mention that, because it' _doesn't_ work.

After some banging around, I have a fix that _does_ work:

1390c1390
<         } elseif ($dataCrc != crc32($unpacked)) {
---
>         } elseif ((0xffffffff & $dataCrc) !=
(0xffffffff & crc32($unpacked))) {

We've been banging on this on one of our 64-bit FreeBSD
systems, and it's
working flawlessly.  Oddly, it doesn't seem as if any change
is needed to
the header check portion.

> And yes, I'm going to do a bugfix release sometime
soon, but will need to fix 
> #10605 also and revisit the gzip vs. mb_*() changes
done sometime ago.

Good to know.  Let me know if I can be any more help on this
one.

-- 
Bill Moran
Collaborative Fusion Inc.
http:/
/people.collaborativefusion.com/~wmoran/

wmorancollaborativefusion.com
Phone: 412-422-3463x4023

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php