=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

=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

=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

=begin
2010/8/20 Daniel Gutmanas [email protected]:

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

=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