Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The C23 edition of Modern C

gustedt.wordpress.com

Post reply on HN
Print view View original

301–310 of 360 posts

Re: The C23 edition of Modern C

#301

Post by legends2k »

eqvinox wrote: post #253

> The storage order, the endianness, as given for my machine, is called little-endian. A system that has high-order representation digits first is called big-endian. Both orders are commonly used by modern processor types. Some processors are even able to switch between the two orders on the fly. Calling big endian "commonly used by modern processor types" when s390x is really the only one left is a bit of a stretch…

Arm is bi-endian and is alive in most phones.

I agree with another GP's comment that modern doesn't mean popular/widely used.

Re: The C23 edition of Modern C

#302

Post by School-Cotton »

legends2k wrote: post #301
eqvinox wrote: post #253

> The storage order, the endianness, as given for my machine, is called little-endian. A system that has high-order representation digits first is called big-endian. Both orders are commonly used by modern processor types. Some processors are even able to switch between the two orders on the fly. Calling big endian "commonly used by modern processor types" when s390x is really the only one left is a bit of a stretch…

Arm is bi-endian and is alive in most phones. I agree with another GP's comment that modern doesn't mean popular/widely used.

I really doubt any mainstream smartphone runs their Arm chip in big-endian mode ever.

Re: The C23 edition of Modern C

#303

Post by legends2k »

School-Cotton wrote: post #302
legends2k wrote: post #301

Earlier quoted context omitted.

Arm is bi-endian and is alive in most phones. I agree with another GP's comment that modern doesn't mean popular/widely used.

I really doubt any mainstream smartphone runs their Arm chip in big-endian mode ever.

That's besides the point. The book's author has a valid point. Being pedantic should be applied at all levels if you're going that route.

Re: The C23 edition of Modern C

#304

Post by flohofwoe »

jstarks wrote: post #290
Arch-TK wrote: post #255

Earlier quoted context omitted.

> C library maintainers to support the people how want to compile their C code with a C++ compiler. Just tell them to go away. Trying to write the subset of C and C++ is a fool's errand.

No inline functions in library headers, then.

Inline is mostly pointless in C anyway though.

But it might be a minor problem for STB-style header libraries.

It's not uncommon for C++ projects to include the implementation of an STB-style header into a C++ source file instead of 'isolating' them in a C source file. That's about the only reason why I still support the common C/C++ subset in my C libraries.

Re: The C23 edition of Modern C

#305

Post by Keyframe »

eqvinox wrote: post #253

> The storage order, the endianness, as given for my machine, is called little-endian. A system that has high-order representation digits first is called big-endian. Both orders are commonly used by modern processor types. Some processors are even able to switch between the two orders on the fly. Calling big endian "commonly used by modern processor types" when s390x is really the only one left is a bit of a stretch…

well, network byte order is a thing. Not a processor though.

Re: The C23 edition of Modern C

#306

Post by flohofwoe »

unilynx wrote: post #286
eqvinox wrote: post #253

> The storage order, the endianness, as given for my machine, is called little-endian. A system that has high-order representation digits first is called big-endian. Both orders are commonly used by modern processor types. Some processors are even able to switch between the two orders on the fly. Calling big endian "commonly used by modern processor types" when s390x is really the only one left is a bit of a stretch…

well in a way all processors commonly use them... as big-endian is also the network byte order

...x86 CPUs actually have special mov instructions now to load big endian data. Not sure since when though (on godbolt it needs `-march=native`:

https://www.godbolt.org/z/bWfhGx7xh

...without -march=native it's a mov and bswap (so not too bad either).

Re: The C23 edition of Modern C

#307

Post by kelsey98765431 »

legends2k wrote: post #301
eqvinox wrote: post #253

> The storage order, the endianness, as given for my machine, is called little-endian. A system that has high-order representation digits first is called big-endian. Both orders are commonly used by modern processor types. Some processors are even able to switch between the two orders on the fly. Calling big endian "commonly used by modern processor types" when s390x is really the only one left is a bit of a stretch…

Arm is bi-endian and is alive in most phones. I agree with another GP's comment that modern doesn't mean popular/widely used.

MipsBE is very common in edge devices on many networks. You may have 5 MipsBE devices in your home or office without realizing. It's almost never an issue so nobody cares, but they are common.

Re: The C23 edition of Modern C

#308

Post by flohofwoe »

cpeterso wrote: post #297
flohofwoe wrote: post #239

Earlier quoted context omitted.

Well, not in C :) Here's an example where Clang and GCC don't agree about the behaviour of auto in C23: https://www.godbolt.org/z/WchMK18vx IIRC Clang implements 'C++ semantics' for C23 auto, while GCC doesn't. Last time I brought that up it turned out that both behaviours are 'standard compliant', because the C23 standard explicitly allows such differing behaviour (it basically standardized the status quo even if di…

> PS: at least Clang has a warning now in pedantic mode: https://www.godbolt.org/z/ovj5r4axn Did you mean gcc? Your link shows a gcc error: :3:5: error: 'auto' requires a plain identifier, possibly with attributes, as declarator 3 | auto* p = &i; | ^~~~

No, GCC is right to error there, because the code uses a C++-ism (the '*' after 'auto' only makes sense in C++ but not in C).

Re: The C23 edition of Modern C

#310

Post by eqvinox »

throwaway19972 wrote: post #293
eqvinox wrote: post #265

Earlier quoted context omitted.

Uh, why so serious? I called it "a bit of a stretch ;D" - there was a reason for that smiley. I'm well aware BE is alive enough to be around. If you can't live without knowing, sure, my stake in dismissing big endian architectures is that I can't in fact dismiss BE architectures because I have users on it. And it's incredibly painful to test because while my users have such hardware, actually buying a good test platf…

> there was a reason for that smiley Fair—my bad, I can fail at reading tone sometimes. Would you propose the C abstract machine abstracting away endianness entirely as an alternative? My understanding is that deprecating support for existing architectures is discouraged to every practical extent.

Maybe we failed to communicate because our brains have different endianness? :D

To be honest, I don't think this is a solvable problem. (Changing the C machine concept doesn't do much if you need to process network traffic that uses both (e.g. IP packet [big endian] carrying protobuf [little endian]). It's already mostly a question of data ingress/egress.)

What is solvable though is making sure people are sufficiently aware. And the people who read a book like "Modern C" are probably a very good target audience, building low-level bindings and abstractions. They should know that LE and BE are technically a free-floating design choice, but practically the vast majority of systems is LE now. But at the same time, yes, BE isn't extinct, and won't be any time soon… and it's left to them to make their best possible design given their environments.

Post reply on HN