Live data from Hacker News

The Byte Order Fiasco

justine.lol

261–270 of 378 posts

Re: The Byte Order Fiasco

#261
post #243
post #74

Earlier quoted context omitted.

> There is a huge mismatch between the assumptions of the C spec and actual machine code. Right, which is why the kind of UB pedantry in the linked article is hurting and not helping. Cranky old man perspective here: Folks: the fact that compilers will routinely exploit edge cases in undefined behavior in the language specification to miscompile obvious idiomatic code is a terrible bug in the compilers . Period. And…

I agree but language of the standard very unambiguously lets them do it. Quoth X3.159-1988 * Undefined behavior --- behavior, upon use of a nonportable or erroneous program construct, of erroneous data, or of indeterminately-valued objects, for which the Standard imposes no requirements. Permissible undefined behavior ranges from ignoring the situation completely with unpredictable results, to behaving during transla…

So let's fix our code.

No; I say we force the compiler writers to fix their idiotic assumptions instead of bending over backwards to please what's essentially a tiny minority. There's a lot more programmers who are not compiler writers.

The standard is really a minimum bar to meet, and what's not defined by it is left to the discretion of the implementers, who should be doing their best to follow the "spirit of C", which ultimately means behaving sanely. "But the standard allows it" should never be a valid argument --- the standard allows a lot of other things, not all of which make sense.

A related rant by Linus Torvalds: https://bugzilla.redhat.com/show_bug.cgi?id=638477#c129

Re: The Byte Order Fiasco

#262
post #225

Earlier quoted context omitted.

The irony is that while a tiny PIC can do bit banging easily, the mighty Pi will struggle with it.

I'm familiar with both, and have Pi's bit-banging at 8MHz. It's not hard-realtime like a PIC though (where I've bitbanged a resistor D2A hung off a dsPIC33 to 17.734475MHz). It's an improvement over the years, but surprisingly little since bit-banging 4MHz Z80's more than 4 decades ago, where resolution was 1 T state (250ns).

The 9 bit serial OP mentioned likely doesn't have a seperate clock line, so it is hard realtime and timing matters a lot, and I doubt the Pi could reliably do anything over 1 kHz baud with bit banging. You could do much better if you didn't run Linux.

Re: The Byte Order Fiasco

#263

Earlier quoted context omitted.

Sorry, dumb question: what is bit banging?

In order to exchange data over a serial connection, the ones and zeroes have to be sent with exact timing, so the receiver can reliably tell where one bit ends and the next begins. Because of this, the hardware that's doing the communication can't do anything else at the same time. And since the actual mechanics of the process are simple and straightforward, most computers with a serial connection have special serial…

Consider being a teacher. Thats a good explanation.

Re: The Byte Order Fiasco

#264
post #233

Earlier quoted context omitted.

Every time I see one of these threads, my gratitude to only do backend grows. Human behavior is too complex, let the webdevs handle UI, and human languages are too complex, not sure what speciality handles that. Give me out of order packets and parsing code that skips a character if the packet length lines up just so any day. I am thankful that almost all the Unicode text I see is rendered properly now, farewell the…

I think we really have the iPhone jailbreakers to thank for that. U.S. developers were allergic almost offended by anything that wasn't ASCII and then someone released an app that unlocked the emoji icons that Apple had originally intended only for Japan. Emoji is defined in the astral planes so almost nothing at the time was capable of understanding them, yet were so irresistible that developers worldwide who would…

I'm pretty sure Unicode was pretty widespread before the iphone/emoji popularity.

Re: The Byte Order Fiasco

#265
post #239

Earlier quoted context omitted.

There was a blog post and a FOSDEM presentation by (misguided) Gentoo developers a few years ago, and it was retracted, because sanitizers add their own exploitable vulnerabilities due to the way they work. https://blog.hboeck.de/archives/879-Safer-use-of-C-code-runn... https://www.openwall.com/lists/oss-security/2016/02/17/9

Sanitizers have the ability to bring Rust-like safety assurances to all the C/C++ code that exists. The fact that existing ASAN runtimes weren't designed for setuid binaries shouldn't dissuade us from pursuing those benefits. We just need a production-worthy runtime that does less things. For example, here's the ASAN runtime that's used for the redbean web server: https://github.com/jart/cosmopolitan/blob/master/libc…

Run-time detection and heuristics on a language that is hard to analyze (e.g. due to weak aliasing, useless const, ad-hoc ownership and thread-safety rules) aren't in the same ballpark as compile-time safety guaranteed by construction, and an entire modern ecosystem centered around safety. Rust can use LLVM sanitizers in addition to its own checks, so that's not even a trade-off.

Re: The Byte Order Fiasco

#266
post #204

Earlier quoted context omitted.

Not sure what you think the source code "says". I mean, I know what you want it to mean, but just because integer wrapping is intuitive to you doesn't imply that that is what the code means. C++ abstract machine and all. But to answer the actual question: For C++20, integer types were revisited. It is now (finally) guaranteed that signed integers are two's complement, along with a list of other changes. See http://ww…

I haven't noticed the signed integer overflow, which does indeed complicate things, and I thought it was just the infinite loop UB. > Data from Google suggesting that over 90% of all overflow is a bug, and defining wrapping behavior would not have solved the bug. Of all overflow? Including unsigned integers where the behavior is defined?

That 90% of all overflows are bugs doesn't surprise me at all, even if you include unsigned integers.

Re: The Byte Order Fiasco

#267
post #75

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…

> 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.

Re: The Byte Order Fiasco

#268

Earlier quoted context omitted.

I agree with the bulk of this post. Re the anecdata at the end. Have you ever run your code through the sanitizers? I have. CVE-2016-2414 is one of my battle scars, and I consider myself a pretty good programmer who is aware of security implications.

Raph, clearly you're just not as good a programmer as you think you are.

Why thank you Vitali. Coming from you, that is high praise indeed.

Re: The Byte Order Fiasco

#269
post #77

Earlier quoted context omitted.

Little endian. There is no extant big-endian CPU that matters.

I did say in an ideal world.

Hint: The reason why it's called "endianness" comes from the novel Gulliver's Travels, in which the neighboring nations of Lilliput and Blefuscu went to bitter, bloody war over which end to break your eggs from: the big end or the little end. The warring factions were also known as Big-Endians and Little-Endians, and each thought themselves superior to the dirty heathens on the other side. If one side were objectively correct, if there were an inherent advantage to breaking your egg from one side or the other, would there be a war at all?

Re: The Byte Order Fiasco

#270

Earlier quoted context omitted.

I did say in an ideal world.

Hint: The reason why it's called "endianness" comes from the novel Gulliver's Travels , in which the neighboring nations of Lilliput and Blefuscu went to bitter, bloody war over which end to break your eggs from: the big end or the little end. The warring factions were also known as Big-Endians and Little-Endians, and each thought themselves superior to the dirty heathens on the other side. If one side were objective…

> if there were an inherent advantage to breaking your egg from one side or the other, would there be a war at all?

Fascism vs. not-fascism, Stalinist Communism vs. Western Capitalism, Islamism vs. liberal democracy... I’m not sure “the existence of war around a divide in ideas proves that neither sides ideas are correct” is a particularly comfortable maxim to consider the ramifications of.

Post reply on HN