4 ms·

Bigendian ints in the header? Why.

• jiggawatts 4y ago
  Because SPARC is making a comeback any day now!
• Retr0id 4y ago
  The computational cost of an endian swap rounds to zero, and file format implementers expect serialised ints to be big-endian by default. It's just the Principle of Least Astonishment at this point.
  • Const-me 4y ago
    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)
  • elteto 4y ago
    The principle of least astonishment in a little endian world is a big endian value? I don’t buy that. Maybe we are in the transition phase to where little endian IS the least astonishing thing to do :p
    • Retr0id 4y ago
      In protocols and file formats, specifically.
• dale_glass 4y ago
  Also no room for a version number or extensions. You know that sooner or later something else is going to be needed. Eg, HDR.
• kristopolous 4y ago
  network byte order
  • rasz 4y ago
    was a mistake we all pay for daily
    • kristopolous 4y ago
      Oh ntohsense!