Incorrect endianness in OFF file handling about pmp-library HOT 6 CLOSED

Not sure about this one. Seems more like a historical artifact due to the systems of that time being big endian. From the Geomview page:

This is the native format for 'int's and 'float's on Sun-3's, Sun-4's, and Irises, among others.

I'm not even sure if correct endianness conversion is feasible for floats, see also the Boost.Endian FAQ. Looks like simply swapping bytes around is not sufficient.

from pmp-library.

Well it's not like big-endian systems completely disappeared anyway, POWER9 can handle both, so using native-endian for a binary on-disk format is really a bad idea.

from pmp-library.

While naive byte swapping may not work well, there are other ways of performing floating point binary I/O, e.g. https://github.com/MalcolmMcLean/ieee754

from pmp-library.

After writing the above I was thinking about how protobuf does binary float encoding, and it looks like they just assume the same endinaness as int32_t and use that to write little endian binaries: https://github.com/protocolbuffers/protobuf/blob/5d876c9fec1a6f2feb0750694f803f89312bffff/src/google/protobuf/wire_format_lite.h#L827

from pmp-library.

I agree it would be nice to make this consistent with the spec. I'll give it a shot, not sure when I'll find time though.

from pmp-library.

Our CI is not yet ready for some C++23 functionality I was using to implement this.

from pmp-library.