Possible Zlib Bug

[Jed Hurt]

I originally posted this message to core as I assumed that it would be
the mailing list with
the most knowledge of Ruby's Zlib library, but received no reply, so
I'm posting it again here.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D

I'm porting SWX PHP ( swxformat.org ) to Ruby (
http://rubyforge.org/projects/rswx ). SWX is a data exchange format=97a
replacement for Flash Remoting, SOAP, et al. The idea is to assemble
Flash SWF files by converting Ruby objects (hashes, array, strings,
integers, etc.) to SWF bytecode.

SWF files support compression using ZLib, and so I'm implementing
compression using
Ruby's ZLib library.

As I'm porting SWX PHP to Ruby, I am able to generate a SWF file using
SWX PHP to see what I need to generate in rSWX ( my port ).

There seems to be a bug in Ruby's ZLib implementation that creates a
different header and trailer than PHP's gzcompress() (the function
used to compress in SWX PHP).

Here is the bytecode of two SWF files containing the same data (one
generated with SWX PHP and the other generated with rSWX):
http://pastie.caboo.se/95038

I've highlighted the discrepant parts of the two files (Please note
that the first 8 bits of a compressed SWF file are left uncompressed,
thus the header of the compressed section of the file starts on the
second line of the pastied result).

And, needless to say, the compressed SWF file generated with SWX PHP
works, and the one generated with rSWX does not.

I know very little about compression or Zlib so I'm quite lost at this
point. I've tried to make this post as thorough as possible so that
someone with a greater knowledge of hex bytecode could help me fix the
issue without much effort. If I could post anything else to make it
easier to find the issue, please let me know and I'll be happy to do
it.

 

[yermej]

I originally posted this message to core as I assumed that it would be
the mailing list with
the most knowledge of Ruby's Zlib library, but received no reply, so
I'm posting it again here.
====================================================

I'm porting SWX PHP ( swxformat.org ) to Ruby (http://rubyforge.org/projects/rswx). SWX is a data exchange format-a
replacement for Flash Remoting, SOAP, et al. The idea is to assemble
Flash SWF files by converting Ruby objects (hashes, array, strings,
integers, etc.) to SWF bytecode.

SWF files support compression using ZLib, and so I'm implementing
compression using
Ruby's ZLib library.

As I'm porting SWX PHP to Ruby, I am able to generate a SWF file using
SWX PHP to see what I need to generate in rSWX ( my port ).

There seems to be a bug in Ruby's ZLib implementation that creates a
different header and trailer than PHP's gzcompress() (the function
used to compress in SWX PHP).

Here is the bytecode of two SWF files containing the same data (one
generated with SWX PHP and the other generated with rSWX):http://pastie.caboo.se/95038

I've highlighted the discrepant parts of the two files (Please note
that the first 8 bits of a compressed SWF file are left uncompressed,
thus the header of the compressed section of the file starts on the
second line of the pastied result).

And, needless to say, the compressed SWF file generated with SWX PHP
works, and the one generated with rSWX does not.

I know very little about compression or Zlib so I'm quite lost at this
point. I've tried to make this post as thorough as possible so that
someone with a greater knowledge of hex bytecode could help me fix the
issue without much effort. If I could post anything else to make it
easier to find the issue, please let me know and I'll be happy to do
it.

I don't know much about zlib, but I did notice one thing in your
pastie example. This:

swx_file.slice!(0..8)

removes 9 bytes from the string. Maybe that should be:

swx_file.slice!(0,8), or
swx_file.slice!(0..7)

?

Jeremy

 

[Jed Hurt]

Well, I'm thoroughly embarrassed. Maybe that's why no one would take
me seriously on the core mailing list. Case closed.