2 ms·
An implementation that memcpy()'s little-endian ints into a struct (without le32toh() or similar) would be subtly incorrect, breaking whenever somebody dares t
by Retr0id 4y ago
An implementation that memcpy()'s little-endian ints into a struct (without le32toh() or similar) would be subtly incorrect, breaking whenever somebody dares to run your code on a big-endian platform.
The "problem" is there either way, and I'd rather have it be noticeable immediately, than at an unknown point in the future.
- Retr0id 4y agoIn other words, serialising an int into bytes is an operation that fundamentally requires you to care about endianness, if you want your files and/or implementation to be platform-interchangeable. A format that tricks you into thinking you don't need to think about it is a suboptimal one, in my opinion.
- Const-me 4y agoDesigning software for hypothetical future which is very unlikely to happen is a classic case of overengineering. Little-endian platforms have won, very few people are targeting MIPS, power or SPARC processors these days. Technically some ARM CPUs are bi-endian, but practically all operating systems people run on them are only supporting little-endian mode. GPUs are little-endian as well.
- Retr0id 4y agoBE systems aren't a hypothetical future, they're here in the present, in production systems. Yes, they're not very common, but that only makes the edge-cases sharper. The overengineering argument would make sense for a specific implementation, but not for the format as a whole, IMHO.
- Const-me 4y agoIt’s not a database format, it’s an image format. They are typically used in conjunction with a graphical display capable of rendering these images. I don’t think many of these legacy BE systems have such a thing. AFAIK most of these systems are headless: supercomputers with Power10, networking equipment, old SPARC servers, etc.
- circuit10 4y agoI’m developing things for a big-endian architecture at the moment (making games and things for my Casio calculator using SuperH)