[googletest] Re: [googlemock: 811] Re: Print test fails on big endian architectures

[Vlad Losev]

[+googletestframework, as universal printer has moved to Google Test, post 1.5]

Fredrik -

I have added issue 286 to track this. Please star the issue to get updates.

I think we definitely want to fix this in Google Test. One issue that I think merits discussion on the list is whether we want to fix the problem by changing the universal printer to use either little- or big-endian representation. Currently it's system-dependent.

I'm leaning towards big-endian because we have readily available POSIX-compliant functions to convert between it and the host order. htole32() and le32toh() are available under Linux and BSD but I was unable to find them in POSIX or on Windows.

It's possible to just amend the tests, but that will make it impossible - either for us or for our users - to create multi-platform golden files while using the universal printer and unprintable types.

2010/5/20 Zhanyong Wan (λx.x x) <w...@google.com>

+googlemock (you need to subscribe to the list in order to post)

On Wed, May 19, 2010 at 11:56 PM, Fredrik Hallenberg
<megah...@gmail.com> wrote:
> Hi, the group address apparently does not work so I am forwarding  this
> directly to you.
>
> Thanks
>
> ---------- Forwarded message ----------
> From: Fredrik Hallenberg <megah...@gmail.com>
> Date: Thu, May 20, 2010 at 8:46 AM
> Subject: Print test fails on big endian architectures
> To: googl...@googlegroups.com
>
>
> Hi, google-mock is now included in Debian. While building the package I
> discovered that some tests related to
> "UnprintableInFoo" in gmock-printers_test.cc only worked on little endian
> machines.
>
> On Debians configurations of HPPA, PowerPC, S390, Sparc, and MIPS to
> following tests failed::
>
> test/gmock-printers_test.cc:866: Failure
> Value of: Print(::foo::UnprintableInFoo())
>  Actual: "16-byte object <0000 12EF 0000 AB34 0000 0000 0000 0000>"
> Expected: "16-byte object <EF12 0000 34AB 0000 0000 0000 0000 0000>"
>
> ...
>
> test/gmock-printers_test.cc:967: Failure
> Value of: PrintByRef(x)
>  Actual: "@0xfaff0628 16-byte object <0000 12EF 0000 AB34 0000 0000 0000
> 0000>"
> Expected: "@" + PrintPointer(&x) + " 16-byte object " "<EF12 0000 34AB 0000
> 0000 0000 0000 0000>"
> Which is: "@0xfaff0628 16-byte object <EF12 0000 34AB 0000 0000 0000 0000
> 0000>"
>
>
> I did the following simple patch:
>
> --- google-mock-1.4.0.orig/test/gmock-printers_test.cc
> +++ google-mock-1.4.0/test/gmock-printers_test.cc
> @@ -86,7 +87,8 @@ namespace foo {
>  // A user-defined unprintable type in a user namespace.
>  class UnprintableInFoo {
>   public:
> -  UnprintableInFoo() : x_(0x12EF), y_(0xAB34), z_(0) {}
> +
> +  UnprintableInFoo() : x_(htole32(0x12EF)), y_(htole32(0xAB34)), z_(0) {}
>   private:
>    testing::internal::Int32 x_;
>    testing::internal::Int32 y_;
>
> and the package now builds correctly.
>
> I suppose this can be done in a better way by changing the printer thingy
> instead but I have not looked at this in detail.
> If someone can advise on how to do a better fix I can incorporate that in
> the package. Of course, if it is fixed in the
> upstream code that is even better.
>
> Best regards,
>
> Fredrik
>
>
>



--
Zhanyong

Regards,
Vlad

[James Youngman]

2010/5/20 Vlad Losev <vl...@losev.com>:

Clearly the problem here is that we are printing an unidentified block
of storage as words when bytes would have been a more portable choice.
Why not just print the bytes and avoid the whole big- versus little-
endian issue?

James.

[James Youngman]

(this time with the correct From: address, too)


2010/5/20 James Youngman <ja...@youngman.org>:

[Zhanyong Wan (λx.x x)]

Despite the look, we *are* actually printing the memory as bytes. i.e.
when the memory contains bytes { 0x12, 0x34, 0x56 }, we print

<1234 56>

regardless of the endianese of the machine. The idea is to group the
bytes in pairs for easy (human) parsing.

In light of the endianese issue, this format is likely to create
confusion. It's a separate issue that we should fix. Which format
should we use? I don't like

<12 34 ... 56>

as it's hard to count the bytes when the object is big. Maybe we
should insert a newline every 8 bytes?

--
Zhanyong

[Zhanyong Wan (λx.x x)]

On Thu, May 20, 2010 at 12:49 AM, Vlad Losev <vl...@losev.com> wrote:
> [+googletestframework, as universal printer has moved to Google Test, post
> 1.5]
> Fredrik -
> I have added issue 286 to track this. Please star the issue to get updates.
> I think we definitely want to fix this in Google Test. One issue that I
> think merits discussion on the list is whether we want to fix the problem by
> changing the universal printer to use either little- or big-endian
> representation. Currently it's system-dependent.
>
> I'm leaning towards big-endian because we have readily available
> POSIX-compliant functions to convert between it and the host
> order. htole32() and le32toh() are available under Linux and BSD but I was
> unable to find them in POSIX or on Windows.

The universal printer should *not* use either endianese. It should
just print raw bytes as it currently does (although with a less
confusing format). Endianese is meaningless here as the printer has
no idea which parts of the byte sequence represent a word.

> It's possible to just amend the tests, but that will make it impossible -

Fixing the tests is the right thing to do here.

> either for us or for our users - to create multi-platform golden files while
> using the universal printer and unprintable types.

Either the test should filter out the actual bytes in such a golden
file, or it should use one-byte objects.

--
Zhanyong

[Vlad Losev]

2010/5/20 Zhanyong Wan (λx.x x) <w...@google.com>

On Thu, May 20, 2010 at 12:49 AM, Vlad Losev <vl...@losev.com> wrote:
> [+googletestframework, as universal printer has moved to Google Test, post
> 1.5]
> Fredrik -
> I have added issue 286 to track this. Please star the issue to get updates.
> I think we definitely want to fix this in Google Test. One issue that I
> think merits discussion on the list is whether we want to fix the problem by
> changing the universal printer to use either little- or big-endian
> representation. Currently it's system-dependent.
>
> I'm leaning towards big-endian because we have readily available
> POSIX-compliant functions to convert between it and the host
> order. htole32() and le32toh() are available under Linux and BSD but I was
> unable to find them in POSIX or on Windows.

The universal printer should *not* use either endianese.  It should
just print raw bytes as it currently does (although with a less
confusing format).  Endianese is meaningless here as the printer has
no idea which parts of the byte sequence represent a word.

> It's possible to just amend the tests, but that will make it impossible -

Fixing the tests is the right thing to do here.

> either for us or for our users - to create multi-platform golden files while
> using the universal printer and unprintable types.

Either the test should filter out the actual bytes in such a golden
file, or it should use one-byte objects.

You are right, the byte array is probably the right idea. 

[Vlad Losev]

This is fixed in r437.

2010/5/20 Vlad Losev <vl...@losev.com>