Would you please list out the architectures for me that you would like getting fixed?

From the performance point of view, it may make sense to keep my original code intact and then to flip a set of byte quads all at once.

Thanks

Would you please list out the architectures for me that you would like getting fixed?

All the architectures listed as BE here: https://wiki.debian.org/ArchitectureSpecificsMemo, so these:

• avr32
• hppa
• m68k
• mips
• powerpc
• ppc64
• s390
• s390x
• sparc
• sparc64

From the performance point of view, it may make sense to keep my original code intact and then to flip a set of byte quads all at once.

Are there really much performance gains to be had here? The original admesh STL binary output code was correct on big-endian architectures before you broke it in the same commit as your static_asserts.

If you're really concerned about the performance here, I can rework it to do all the byteflipping operations using htole32 and memcpying them into a large buffer before fwrite()ing them all in one go, but I don't think we should byteflip the floats in the struct in place as it may end up as a signalling NaN which may then be silently rewritten into a quiet NaN (I think) on some architectures.

I have to admit I have no experience whatsoever with the big endian architectures. I used to work for SuSE in 2000 as a package manager, where I was responsible for packages being compiled on big endian architectures, but I don't remember the little / big endian issues and resolutions anymore.

If you're really concerned about the performance here, I can rework it to do all the byteflipping operations using htole32 and memcpying them into a large buffer before fwrite()ing them all in one go,

I sketched a prototype already. I will make a branch for you to review.

but I don't think we should byteflip the floats in the struct in place as it may end up as a signalling NaN which may then be silently rewritten into a quiet NaN (I think) on some architectures.

Again, I am not sure what the correct handling of NaN, infinities and such should be. In my experience the STLs produced by various modeling software are often buggy and they contain some of these corner cases. For example, I have seen openscad producing some triangle normals with NaNs, and I have patched the admesh to gracefully handle the invalid normals. Taking the state of the STL generators into account, this seems to me the way to go.

Would you please review the following?
a52a045

I tried to maintain the performance while keeping the changes minimal. Is this acceptable to you?

Thanks

I see you've already committed a52a045 onto master, so I'll close this PR.

Please consider what I said in my previous post about byteflipping floats in-place though.

Please read https://groups.google.com/d/msg/boost-list/DgB0DyiZeCE/xv_1S7BKCAAJ
for complications when it comes to byte swapping floats. I don't think you need
to actually access it as a float to cause issues. The way I understand it, just
playing around with the bytes of a char* that's aliased with a float can also
cause issues.

Thanks. I believe my code should be fine. The only risk I see is in the reading routine, where in theory the compiler could access the facet floats before the byte swapping. I believe though, that a correct compiler should detect the aliasing on stlinit.cpp:277 before accessing the floating point data on line 362 and outside the function.