Bug #8935
closed
Zlib::GzipWriter.new with block truncates output to 20 corrupted bytes
Added by bugmenot123 (DoNot BugMe) over 10 years ago.
Updated almost 5 years ago.
Description
=begin
(({Zlib::GzipWriter.new})) with block truncates output to 20 corrupted bytes.
#!/usr/bin/ruby -w
require "zlib"
require "stringio"
input = File.read "/dev/urandom", 200
corrupted and only 20 bytes long:
out1 = Zlib::GzipWriter.new(StringIO.new){ |gz| gz.write input }.close.string
puts out1.bytesize, out1.inspect, ""
good:
writer = Zlib::GzipWriter.new(StringIO.new)
writer.write input
out2 = writer.close.string
puts out2.bytesize, out2.inspect
=end
Sorry, another try without any formatting:
#!/usr/bin/ruby -w
require "zlib"
require "stringio"
input = File.read "/dev/urandom", 200
corrupted and only 20 bytes long:¶
out1 = Zlib::GzipWriter.new(StringIO.new){ |gz| gz.write input }.close.string
puts out1.bytesize, out1.inspect, ""
good:¶
writer = Zlib::GzipWriter.new(StringIO.new)
writer.write input
out2 = writer.close.string
puts out2.bytesize, out2.inspect
- Description updated (diff)
Come to think of it, 20 bytes seems like what the gzip header + footer would take up...
Every ruby method can be accept a block.
Zlib::GzipWriter.new just return a object, not callback the block,
Zlib::GzipWriter.new(StringIO.new){ |gz| gz.write input }.close.string
is equal
Zlib::GzipWriter.new(StringIO.new).close.string
Whoa. Has that always been the case? Cause I'm pretty sure I saw this code used somewhere else too.
The problem with .open, which definitely takes a block, is that it only works with file names, not IO objects and thus not StringIO. But it's not unreasonable to want to transform a string to a gzipped string, right?
- Status changed from Open to Closed
- Backport deleted (
1.9.3: UNKNOWN, 2.0.0: UNKNOWN)
Also available in: Atom
PDF
Like0
Like0Like0Like0Like0Like0Like0