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

Everything in C is undefined behavior

blog.habets.se

Post reply on HN
Print view View original

191–200 of 748 posts

Re: Everything in C is undefined behavior

#191

Post by tovej »

pjc50 wrote: post #132
tovej wrote: post #118

Earlier quoted context omitted.

But that seems obvious. You can't load an integer from an unaligned address. It's not only C-level is it. There's no (guarantee across architectures for) machine code for that either.

You missed the point: the pointer existing as a value of that type at all is UB, even if you never try to access anything through it and no corresponding machine code is ever emitted.

Yes? I agree with that. I don't really see the issue there. The computer will allocate data in aligned addresses, so you would have to be doing something weird to begin with to access unaligned pointers. And aligned access is always better anyway. I guess packed structs are a thing if you're really byte golfing. Maybe compressed network data would also make sense.

But then I would assume you are aware of unaligned pointers, and have a sane way to parse that data, rather than read individual parts of it from a raw pointer.

I am curious, what would be a legitimate reason for an unaligned pointer to int?

Re: Everything in C is undefined behavior

#192

Post by thomashabets2 »

stackghost wrote: post #6

Anyone who uses the construction "C/C++" doesn't write modern C++, and probably isn't very familiar with the recent revisions despite TFA's claims of writing it every day for decades. Far from being just "C with classes", modern C++ is very different than C. The language is huge and complex, for sure, but nobody is forced to use all of it. No HN comment can possibly cover all the use cases of C++ but in general, unle…

Author here.

In the context of UB discussion, the arguments apply equally to C and C++.

How would you write that?

I entirely agree with all your points that C and C++ are completely different languages at this point. And yet I wanted to write this post about something that is true for both.

Re: Everything in C is undefined behavior

#193

Post by keyle »

parasti wrote: post #142

I have never in my 20 years of writing C heard so much about undefined behavior as I have in the past 6 months on Hacker News. It has never entered the conversation. You write the code. If it doesn't work, you debug it and apply a fix or a workaround. Why does the idea of undefined behavior in C get to the front page so consistently?

Computers used to be cool; now they're dangerous.

Every company keep harping on about safety and being exposed (being in the news): so the narrative against 'unsafe' is up the wazoo.

The new world is basically a bunch of city dwellers who haven't seen raw nature and you show them a lawn mower, they freak out. Blades that spin?!?!?! Madness!!

Re: Everything in C is undefined behavior

#194

Post by thomashabets2 »

stackghost wrote: post #23
veltas wrote: post #14

Earlier quoted context omitted.

Although some people, like Bjarne Stroustrup, object to the term C/C++, it's a bit like Richard Stallman objecting to the term "Linux". The fact is it can mean "C or C++", and I wouldn't assume the author thinks they're the same, but they're talking about both of them together in the same sentence. This seems reasonable given this is about undefined behavior, and it's trivial to accidentally write UB-inducing code in…

Well, the author explicitly refers to "C/C++" as one language: >After all, C/C++ is not a memory safe language.

That is a typo, that I think I introduced when I went back to clarify that it applies to C++ too.

Will fix it.

Re: Everything in C is undefined behavior

#195

Post by gblargg »

debugnik wrote: post #49

As much as I agree with the intro, these examples aren't good and the overall article is just a veil for pushing LLM coding.

Agreed. One after another these are standard things you avoid when writing portable code (or don't need, like accessing the object at address 0). They come across like from someone who wants to write whatever they want and have it work the same on everything. To make it into a language that allows this would remove its advantage of being able to write to the platform when you want to.

Re: Everything in C is undefined behavior

#196

Post by hnarn »

account42 wrote: post #166
parasti wrote: post #142

I have never in my 20 years of writing C heard so much about undefined behavior as I have in the past 6 months on Hacker News. It has never entered the conversation. You write the code. If it doesn't work, you debug it and apply a fix or a workaround. Why does the idea of undefined behavior in C get to the front page so consistently?

There are a lot of Rust/whatever hipsters here that have defined their whole identity around hating C and C++.

Ironically, by stereotyping ”Rust hipsters” you are painting yourself out as a stereotype as well. Knee-jerk comments like yours add nothing to the discussion. Rust exists for a reason, it solves real problems, but it’s not suitable for everything. These are indisputable facts and by discarding every mention of Rust as coming from ”hipsters” with no understanding, you are doing the exact same thing that you would accuse them of. ”Use Rust for everything” and ”Rust is useless for everything” are equally vapid and meaningless statements designed for nothing but trolling and showing ignorance.

Re: Everything in C is undefined behavior

#197

Post by HelloNurse »

thomashabets2 wrote: post #163
HelloNurse wrote: post #120

Earlier quoted context omitted.

Some of the examples are somewhat formally true in theory and bullshit in practice; some are quite hallucinatory. - Creating a potentially troublesome misaligned int pointer is a precisely localized and completely explicit user mistake, not something that just happens because it's C. - Passing signed char to character classification functions that expect an unsigned char (disguised as an int) is a very specific dumb…

Author here. So I see your counter points are all "so just don't do that, then". And the point of my post is that this particular "just don't do that, then" has never been achieved by humans. If if there's no example of a program without these bugs in a language, then I do think it's fair to blame the language. A knife with 16 blades and no handle. > Expecting C to handle "address zero" in physical memory in ways tha…

"Just don't do that" is the correct approach to errors, even when they are easy to overlook and the programming language provides many opportunities for mistakes.

For example, you seem to underestimate how wrong placing negative values in a signed char is: ordinary character encodings do not use negative codes, so either those negative values are not characters and they have no business being treated as such, or something strange and experimental is going on.

Re: Everything in C is undefined behavior

#199

Post by sethev »

parasti wrote: post #142

I have never in my 20 years of writing C heard so much about undefined behavior as I have in the past 6 months on Hacker News. It has never entered the conversation. You write the code. If it doesn't work, you debug it and apply a fix or a workaround. Why does the idea of undefined behavior in C get to the front page so consistently?

I wonder if it’s just the colorful metaphors and an opportunity to bring out examples of surprising behavior. Plus it’s a topic that can always stir up debates.

Re: Everything in C is undefined behavior

#200

Post by benj111 »

The issue for me with posts like this is that it misses the issue.

Unaligned pointer accesses are UB because different systems handle it differently. This 'should' be to allow the program to be portable by doing what the system normally does.

Instead it's been highjacked by compiler writers, with the logic that "X is UB, therefore can't happen, therefore can be optimised away."

Int c = abs(a) + abs(b); If (a > c) //overflow

Is UB because some system might do overflow differently. In practice every system wraps around.

That should be a valid check, instead it gets optimised away because it 'can't' happen.

C gives you enough rope to hang yourself. The compiler writers don't trust you to use the rope properly.

Post reply on HN