Bug: Open simple COLLADA file on BigEndian architecture fails (s390x or ppc64)

[mzf-guest]

Describe the bug
Loading the COLLADA example from 1.5 documentation (Appendix A) fails on s390x architecture with the following error description: Expected different index count in <p> element.

It works on any other architectures like amd64 or arm64.

To Reproduce
Build and run the program at: https://salsa.debian.org/mzf/assimp-collada-test

Expected behavior
The importer loads the given COLLADA file without error, like on amd64 architecture.

Screenshots
N/A

Platform (please complete the following information):

• OS: Linux Debian sid
• Version: Assimp version 5.2.5

Additional context
s390x is a Big Endian architecture, which may be the root of the issue. I can do additional check on this architecture to ease debugging, do not hesitate to ask.

This is the forwarding of the Debian issue 1023212

Thanks!

[umlaeute]

the s390x architecture is one of the few remaining BigEndian architectures.
practically all bugs that i've encountered in the recent past that (only) showed up on s390x where related to BigEndian issues (which are rarely tested for these days).

[umlaeute]

so i just ran your test on ppc64 (the other BigEndian architecture that is supported by Debian), and can confirm that the problem is there as well:

$ ./assimp_test_collada 
Info,  T0: Load cube.dae
Debug, T0: Assimp 5.2.0 ppc64 gcc debug shared singlethreadedsingle : 
Info,  T0: Found a matching importer for this file format: Collada Importer.
Info,  T0: Import root directory is './'
Debug, T0: Collada schema version is 1.5.n
Error, T0: Expected different index count in <p> element.
Assimp error: Expected different index count in <p> element.

so it seems that this is indeed a simple BigEndian issue.

[mzf-guest]

Thanks for the additional testing!

so it seems that this is indeed a simple BigEndian issue.

Is there a patch that I can try? otherwise, do you have any insight of the faulty code that I could debug?

[umlaeute]

Is there a patch that I can try? otherwise, do you have any insight of the faulty code that I could debug?

what i meant to say is that for me the double-test confirmed that the issue is indeed ("just") a BigEndian problem, as opposed to a (complicated, hardware-specific) s390x-only problem.
sidenote: you might want to update the title accordingl (replacing "s390x" with "BigEndian")

i did not want to imply (with "a simple BigEndian issue"), that there is a simple and quick fix to the problem.
in fact, i haven't even looked at the code.
the obvious place to look for is around

assimp/code/AssetLib/Collada/ColladaParser.cpp

Lines 1748 to 1759 in cfed745

	// complain if the index count doesn't fit
	if (expectedPointCount > 0 && indices.size() != expectedPointCount * numOffsets) {
	if (pPrimType == Prim_Lines) {
	// HACK: We just fix this number since SketchUp 15.3.331 writes the wrong 'count' for 'lines'
	ReportWarning("Expected different index count in <p> element, %zu instead of %zu.", indices.size(), expectedPointCount * numOffsets);
	pNumPrimitives = (indices.size() / numOffsets) / 2;
	} else {
	throw DeadlyImportError("Expected different index count in <p> element.");
	}
	} else if (expectedPointCount == 0 && (indices.size() % numOffsets) != 0) {
	throw DeadlyImportError("Expected different index count in <p> element.");
	}

[mzf-guest]

Title updated, and I'll try to look at the code you've pointed. Thanks!