Test Constraint::for_is_equal_to_contents_of fails on s390x arch

[souryogurt]

I trying to build and test Cgreen on alternative architectures supported in Fedora,
It seams the test for is_equal_to_contents_of fails on s390x architecture.
Test:

cgreen/tests/constraint_messages_tests.c

Lines 62 to 65 in c0ec1e7

	Ensure(ConstraintMessage, for_is_equal_to_contents_of) {
	int forty_five[45] = {45, 44, 43}, thirty_three[33] = {45, 44, 33};
	assert_that(thirty_three, is_equal_to_contents_of(forty_five, 55));
	}

Steps to reproduce

Actually I building using koji service that has s390x environment, so not sure how to reproduce it on x86 arch :/

Actual result

Comparing output of constraint_messages_tests to expected: 
*** constraint_messages_tests.output.normalized	Mon May 11 18:51:26 2020
--- /builddir/build/BUILD/cgreen-1.2.0/tests/constraint_messages_tests.expected	Thu Aug  8 19:49:09 2019
***************
*** 52,58 ****
  
  constraint_messages_tests.c: Failure: ConstraintMessage -> for_is_equal_to_contents_of 
  	Expected [thirty_three] to [equal contents of] [forty_five]
! 		at offset:			[11]
  			actual value:		[0x21]
  			expected value:		[0x2b]
  
--- 52,58 ----
  
  constraint_messages_tests.c: Failure: ConstraintMessage -> for_is_equal_to_contents_of 
  	Expected [thirty_three] to [equal contents of] [forty_five]
! 		at offset:			[8]
  			actual value:		[0x21]
  			expected value:		[0x2b]

[souryogurt]

I can't suggest any patch yet:/ My previous investigations show that the test works correctly (actual and expected values matching), but offset used in the failure message does not match.

It looks like this might happens because s390x architecture is big-endian. And since the offset value is an address of a byte in the integer in this test, it leads test to fail.

As for #225 It looks like build for this architecture might be just disabled since it is not a primary platform.

I'm not familiar with Debian packaging guides, but this issue might be related to #208 too, since it is one of supported Debian platform. But I'm not sure.

[thoni56]

I was just going to ask about the s390x architecture...

I think this will be hard to fix. The test lines up three integers with low numbers in them:

int forty_five[45] = {45, 44, 43}, thirty_three[33] = {45, 44, 33};

This means that on a little endian (64 bit machines) the bytes will be ordered like:

(45, 0, 0, 0) (44, 0, 0, 0) (43, 0, 0, 0)

and

(45, 0, 0, 0) (44, 0, 0 ,0) (33, 0, 0, 0)

with the difference in byte number 8.

But on a big-endian it will be

(0, 0, 0, 45) (0, 0, 0, 44) (0, 0, 0, 43)

and

(0, 0, 0, 45) (0, 0, 0, 44) (0, 0, 0, 33)

giving the difference in byte 11 instead.

So the difference in test output is correct. It should be this way.

That means that disabling Cgreen on s390x because of this is unfortunate since it actually works perfectly (unless there are other issues...).

I can't immediately figure out how to solve it, though. The test is actually comparing a "golden sample" output with the one you get when running all the (failing) tests in constraint_messages_tests. You'll find the expected output in the test directory.

There is a little script for each "messages" test that does some normalization so that the output is the same on all platforms, but I'm not sure we want to add this to that. It seems like to big a hammer to replace "at position [11]" with "at position [8]" in the output...

[thoni56]

Possibly this test will also fail on architectures where int is 2 or 8 bytes. Have you tried any of those?

On a 2-byte int little-endian architecture you would have

(45, 0) (44, 0) (43, 0)

with the difference being in the 5th byte (or 6th, if it's a big-endian), and similarly, in the 17th or 23rd (if my math-brain is on-line) for a 8-byte int architecture.

Still working as it should on that platform, but with a different offset depending on architecture.

We should probably swap out those tests from "golden sample" text output comparisons to something more programmatic.

[souryogurt]

Just checked @alvinchchen patch. I am confirming that the issue is fixed. So the issue can be closed.

Build with 9768d33 and #241 patches succeseed on all architectures:
https://koji.fedoraproject.org/koji/taskinfo?taskID=55602746