Marshal.dump(obj) as String bug?

[Hampton]

Alright, so I've been scratching my head about this along with some
folks over at #ruby-lang.

This may be a known problem, but after spending a few minutes
searching, I can't find any reference... so I'll document it here.

If you take some object and marshal it, then try and concat that
string, it produces some funny results.

Here is the test case that I've discovered. I'm thinking this is
happening because Marshal sends back some weird characters that are
screwing up the string methods. But, I would still classify that as a
bug, because when an object returns a string, that should always be a
fairly safe string to handle or it should be returning something else.
That would be an invalid or misformed string if you can't even use the
regular expressions on it.

Any help would be greatly appreciated.

#I'm running ruby 1.8.3 on ubuntu
#email hcatlin at gmail.com with any help


class MyObject
def initialize
@name = "testvar"
@array = Array.new
end
end

test = MyObject.new
dumpresult = Marshal.dump(test)
puts 'Result: ' << dumpresult # Expected: "Result: MYOBJECTDUMP"
puts 'Result=' << Marshal.dump(test) #Expected "Result=MYOBJECTDUMP"
puts 'Result: ' + dumpresult # Expected: "Result: MYOBJECTDUMP"
puts 'Result=' + Marshal.dump(test) #Expected "Result=MYOBJECTDUMP"
puts "U=" << Marshal.dump(test) # Expected "U=MYOBJECTDUMP"


#My result is this code below.

#MyObject:
# @array[:
#@name"
#testvar
#MyObject:
# @array[:
#@name"
#testvar
#MyObject:
# @array[:
#@name"
#testvar
#MyObject:
# @array[:
#@name"
#testvar
#MyObject:
# @array[:
#@name"
#testvar

 

[David A. Black]

Hi --

Alright, so I've been scratching my head about this along with some
folks over at #ruby-lang.

This may be a known problem, but after spending a few minutes
searching, I can't find any reference... so I'll document it here.

If you take some object and marshal it, then try and concat that
string, it produces some funny results.

Here is the test case that I've discovered. I'm thinking this is
happening because Marshal sends back some weird characters that are
screwing up the string methods. But, I would still classify that as a
bug, because when an object returns a string, that should always be a
fairly safe string to handle or it should be returning something else.
That would be an invalid or misformed string if you can't even use the
regular expressions on it.

Any help would be greatly appreciated.

#I'm running ruby 1.8.3 on ubuntu
#email hcatlin at gmail.com with any help


class MyObject
def initialize
@name = "testvar"
@array = Array.new
end
end

test = MyObject.new
dumpresult = Marshal.dump(test)
puts 'Result: ' << dumpresult # Expected: "Result: MYOBJECTDUMP"
puts 'Result=' << Marshal.dump(test) #Expected "Result=MYOBJECTDUMP"
puts 'Result: ' + dumpresult # Expected: "Result: MYOBJECTDUMP"
puts 'Result=' + Marshal.dump(test) #Expected "Result=MYOBJECTDUMP"
puts "U=" << Marshal.dump(test) # Expected "U=MYOBJECTDUMP"


#My result is this code below.

#MyObject:
# @array[:
#@name"
#testvar
#MyObject:
# @array[:
#@name"
#testvar
#MyObject:
# @array[:
#@name"
#testvar
#MyObject:
# @array[:
#@name"
#testvar
#MyObject:
# @array[:
#@name"
#testvar

If you use p instead of puts you'll see what's going on:

"Result: \004\010o:\rMyObject\a:\v@array[\000:\n@name\"\ftestvar"

Note the \r, which does a carriage return. Then what follows
overwrites what came before (when you do a puts).

You can work around this by doing:

puts "Result:\n" << dumpresult


David

 

[James Edward Gray II]

I'm thinking this is happening because Marshal sends back some
weird characters that are
screwing up the string methods. But, I would still classify that as a
bug, because when an object returns a string, that should always be a
fairly safe string to handle or it should be returning something else.

I think of Marshal as returning binary data. In Ruby, we store that
in a String.

James Edward Gray II

 

[Hampton]

Thanks david, that makes a lot of sense.

Also, it makes sense as to why socket.gets was having issues with
it.... because it was stopping at the \r.

Thanks,
Hampton.