4 ms·

Yeah, computational cost is indeed pretty close to zero. However, mental overhead of developers, and technical complexity of the implementation, is not zero. Th

Yeah, computational cost is indeed pretty close to zero. However, mental overhead of developers, and technical complexity of the implementation, is not zero. These things cost development time, and most importantly they cause bugs. A principle of least astonishment is being able to memcpy() a structure or mmap() a file, and get the correct numbers in the fields without swapping bytes all the time.

deleted 4y ago
[deleted]
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 ago
  In 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 ago
  Designing 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 ago
    BE 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 ago
      It’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.
      - Retr0id 4y ago
        It's not unreasonable for a headless system to be doing image processing.
      - circuit10 4y ago
        My graphing calculator is big-endian
  - circuit10 4y ago
    I’m developing things for a big-endian architecture at the moment (making games and things for my Casio calculator using SuperH)

deleted 4y ago

[deleted]

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 ago
In 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 ago
Designing 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 ago
  BE 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 ago
    It’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.
    - Retr0id 4y ago
      It's not unreasonable for a headless system to be doing image processing.
    - circuit10 4y ago
      My graphing calculator is big-endian
- circuit10 4y ago
  I’m developing things for a big-endian architecture at the moment (making games and things for my Casio calculator using SuperH)