Bug #3721: Unsigned formats broken in 1.9.2's unpack

• Status: Closed
• Assignee: usa (Usaku NAKAMURA)
• Target version: -
• ruby -v: ruby 1.9.2p0 (2010-08-18 revision 29036) [x64-mswin64_100]

[Noxerus (D. G.)]

=begin
When specifying the V format code, unpack should treat the four bytes as an unsigned long integer. As can be seen in the following example, it treats it as a signed integer instead:
"\xFF\xFF\xFF\xFF".unpack(?V) => [-1]
The same code worked properly in 1.9.1.

By the way, the same problem occurs for the N and L format codes.
=end

[luislavena (Luis Lavena)]

=begin
Is this the expected result?

ruby.exe -ve 'puts "\xFF\xFF\xFF\xFF".unpack(?V)'
ruby 1.9.2p0 (2010-08-18) [i386-mingw32]
4294967295

If so, then GCC compiled Ruby works.
=end

[Noxerus (D. G.)]

=begin
Yes, 4294967295 is the expected result.

I've just tried the same code in a 32-bit build (ruby 1.9.2p0 (2010-08-18 revision 29036) [i386-mswin32_100]), and it also gives the correct result:
"\xFF\xFF\xFF\xFF".unpack(?V) => [4294967295]

I wonder if this bug manifests only when using the 64-bit version of Visual C++, or with other 64-bit compilers as well.
=end

[luislavena (Luis Lavena)]

=begin
Wrapping right now RubyInstaller 1.9.2-p0 release, but will fire a x64 compilation with GCC and report back in a few hours.

=end

[nobu (Nobuyoshi Nakada)]

• Category set to core
• Status changed from Open to Assigned
• Assignee set to usa (Usaku NAKAMURA)

=begin

=end

[akr (Akira Tanaka)]

=begin
2010/8/20 Daniel Gutmanas [e-mail]:

Bug #3721: Unsigned formats broken in 1.9.2's unpack
http://redmine.ruby-lang.org/issues/show/3721

Author: Daniel Gutmanas
Status: Open, Priority: Normal
ruby -v: ruby 1.9.2p0 (2010-08-18 revision 29036) [x64-mswin64_100]

When specifying the V format code, unpack should treat the four bytes as an unsigned long integer. As can be seen in the following example, it treats it as a signed integer instead:
"\xFF\xFF\xFF\xFF".unpack(?V) => [-1]
The same code worked properly in 1.9.1.

It seems a problem on LLP64 environments.

How about this patch?

Index: include/ruby/ruby.h

--- include/ruby/ruby.h (revision 29051)
+++ include/ruby/ruby.h (working copy)
@@ -952,7 +952,7 @@ struct RBignum {
#define OBJ_FROZEN(x) (!!FL_TEST((x), FL_FREEZE))
#define OBJ_FREEZE(x) FL_SET((x), FL_FREEZE)

-#if SIZEOF_INT < SIZEOF_VALUE
+#if SIZEOF_INT < SIZEOF_LONG

define INT2NUM(v) INT2FIX((int)(v))

define UINT2NUM(v) LONG2FIX((unsigned int)(v))

#else

Tanaka Akira

=end

[Noxerus (D. G.)]

=begin
Thanks, the patch seems to fix it!
Perhaps it's worthwhile to extend the "make test" suite of self-tests to verify the expected behavior of the unpack method?
=end

[akr (Akira Tanaka)]

• Status changed from Assigned to Closed
• % Done changed from 0 to 100

=begin
This issue was solved with changeset r29068.
Daniel, thank you for reporting this issue.
Your contribution to Ruby is greatly appreciated.
May Ruby be with you.

=end