The Byte Order Fiasco

Post by alexvoda » Sun, May 09, 2021, 9:14 PM UTC

captainmuon wrote: post #41

It is a ridiculous feature of modern C that you have to write the super verbose "mask and shift" code, which then gets compiled to a simple `mov` and maybe a `bswap`. Wheras, the direct equivalent in C, an assignment with a (type changing) cast, is illegal. There is a huge mismatch between the assumptions of the C spec and actual machine code. One of the few reasons I ever even reached to C is the ability to slurp in…

Post by alexvoda » Sun, May 09, 2021, 9:24 PM UTC

lanstin wrote: post #214

simias wrote: post #66

Earlier quoted context omitted.

> Wheras, the direct equivalent in C, an assignment with a (type changing) cast, is illegal. I don't understand what you mean by that. The direct equivalent of what? Endianess is not part of the type system in C so I'm not sure I follow. > I think there should really be a dialect of C(++) where the machine model is exactly the physical machine. Linus agrees with you here, and I disagree with both of you. Some UBs cou…

I am sympathetic, but portability was more important in the past and gets less important each year. I used to write code strictly keeping the difference between numeric types and sequences of bytes in mind, hoping to one day run on an Alpha or a Tandem or something, but it has been a long time since I have written code that runs on non-(Intel AMD or le ARM)

Post by spacechild1 » Sun, May 09, 2021, 11:02 PM UTC

BlueTemplar wrote: post #341

spacechild1 wrote: post #331

Earlier quoted context omitted.

MIDI (8 bit), 16 bit PCM, 24 PCM and basically any compressed data format (which is always byte based, because the idea is to save memory). You obviously don't care about memory, but many people do!

But compressed data formats aren't going to care about byte size for this very reason...

Post by jart » Mon, May 10, 2021, 1:22 AM UTC

alexvoda wrote: post #342

captainmuon wrote: post #41

It is a ridiculous feature of modern C that you have to write the super verbose "mask and shift" code, which then gets compiled to a simple `mov` and maybe a `bswap`. Wheras, the direct equivalent in C, an assignment with a (type changing) cast, is illegal. There is a huge mismatch between the assumptions of the C spec and actual machine code. One of the few reasons I ever even reached to C is the ability to slurp in…

> That doesn't mean the compiler can't do optimizations, but it shouldn't do things like prove code as UB and fold everything to a no-op. UB doesn't just mean the compiler can treat it as a no-op. It means the compiler can do whatever it likes and still be compliant with the spec. From the POV of someone consulting the spec, if something results in UB, what it means is: "Don't look here for documentation, look in the…

Post by jart » Mon, May 10, 2021, 2:31 AM UTC

tsimionescu wrote: post #267

cbmuser wrote: post #75

Earlier quoted context omitted.

> One of the few reasons I ever even reached to C is the ability to slurp in data and reinterpret it as a struct, or the ability to reason in which registers things will show up and mix in some `asm` with my C. Which results in undefined behavior according to the C ISO standard. Quote: “2 All declarations that refer to the same object or function shall have compatible type; otherwise, the behavior is undefined.” From…

It should be perfectly fine to do this: union reinterpret { char raw[100]; struct myStruct interpreted; } example; read(fd, &example.raw) struct myStruct dest = interpreted; This is standard-compliant C code, and it is a common way of reading IP addresses from packets, for example.

    struct myStruct example;
    read(fd, &example, sizeof(example));