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

261–270 of 748 posts

Re: Everything in C is undefined behavior

#261

Post by fc417fc802 »

Hendrikto wrote: post #233
pjc50 wrote: post #135

Earlier quoted context omitted.

Java has been jitted for .. decades?

You know what JIT means, right? It means that is is not compiled from the start and indeed runs on a bytecode interpreter until the JIT compiler kicks in.

The java JIT has produced sufficiently fast code for all but the most demanding of HPC applications for going on 20 years. I realize keeping up with new developments can be difficult but the out of date java performance memes are entirely ridiculous by now.

Meanwhile half the world appears to run on cpython of all things.

Re: Everything in C is undefined behavior

#262

Post by simonask »

jstimpfle wrote: post #237
simonask wrote: post #115

Earlier quoted context omitted.

I think the article's point is that you don't actually have to get weird at all to run into UB. Lots of people mistakenly think that C and C++ are "really flexible" because they let you do "what you want". The truth of the matter is that almost every fancy, powerful thing you think you can do is an absolute minefield of UB.

I would agree that C is "really flexible", but I would say it's primarily flexible because it lets you cast say from a void pointer to a typed pointer without requiring much boilerplate. It's also flexible because it lets you control memory layout and resource management patterns quite closely. If you want to be standards correct, yes you have to know the standard well. True. And you can always slip, and learn anothe…

It's not flexible in practice, because knowing the standard isn't optional. If you make the choice to not follow the standard, you're making the choice to write fundamentally broken software. Sometimes with catastrophic consequences.

Re: Everything in C is undefined behavior

#263

Post by virtualritz »

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

Like the author of the article, I write C/C++ since 30 years. Mostly close-to-the-metal code around computer graphics. Actually: wrote.

After switching to Rust five years ago I agree with all the Rust hipsters as far as disliking those languages go.

I just don't talk about it a lot. If every Rust person I know that was a C/C++ developer before was as outspoken about what they think of the latter, you'd see that these people are a majority.

We're just old hands who like to use stuff that works. And most of us don't get attached to code or languages.

It's also difficult to admint to yourself that you were never in command of a language as far as UB/other footguns go, as much as you thought. Or ever, for your enire career. For me that self-realization about C/C++ (enabled by Rust) was a turning point.

Lately you can read about the dichotomy re. AI use.

I.e. developers who define them themselves through what they build/ideas are embracing LLMs; for what they can do.

I.e.: I am what I build.

Whereas developers for whom software engineering is a craft that defines them hate them openly.

I.e.: I am how I build.

Now this seems to suggest to me that maybe Rust developers who openly hate C/C++ squarely belong to the latter group whereas the silent ones belong to the former. It's builders vs programmers. Just different world views.

Also you can not dislike something and still not speak about it. Because you decided to not care.

Re: Everything in C is undefined behavior

#264

Post by simonask »

3form wrote: post #218
simonask wrote: post #115

Earlier quoted context omitted.

I think the article's point is that you don't actually have to get weird at all to run into UB. Lots of people mistakenly think that C and C++ are "really flexible" because they let you do "what you want". The truth of the matter is that almost every fancy, powerful thing you think you can do is an absolute minefield of UB.

At which point it feels like some sort of high-level assembly-like language, which is simple enough to compile efficiently and stay crossplatform, with some primitives for calls, jumps, etc. could find a nice niche. Maybe this already exists, even? A stripped down version of C? A more advanced LLVM IR? I feel like this is a problem that could use a resolution, just maybe not with enough of a scale for anyone to bothe…

Well, Zig is aiming to be a "saner C", and mostly succeeding so far. I hope they make it to production.

Rust is a somewhat more thorough attempt to actually course-correct.

Re: Everything in C is undefined behavior

#265

Post by debugnik »

jb1991 wrote: post #253

Some of the C++ code in this article has not been idiomatic in over a decade, and would be considered a code smell today. The language has evolved into quite a different language than when it was first created. As soon as I saw all of those raw pointers and direct pointer access, it was clear that at least part of this article should be taken with a grain of salt. The other obvious issue with the overall perspective…

I was about to call out that the code is supposed to be C and not C++, but I double checked and I realised it actually says std::atomic, not atomic_int!

Re: Everything in C is undefined behavior

#266

Post by benj111 »

fc417fc802 wrote: post #247
benj111 wrote: post #210

Earlier quoted context omitted.

>It's partly the standards fault here - rather than saying "We don't know how vendors will implement this, so we shall leave it as implementation-defined", they say "We don't know how vendors will implement this, so we will leave it as undefined I'd agree to a point. I still think it's unreasonable for compiler writers to get all lawyery about precise terminology. After all "implementation defined" could still be sub…

But it's genuinely useful. In all seriousness, are you sure you aren't perhaps just using the wrong language? At this point UB and leveraging it for optimization are core parts of the most performant C implementations. That said, I think there are many cases where compilers could make a better effort to link UB they're optimizing against to UB that appears in the code as originally authored and emit a diagnostic or e…

>are you sure you aren't perhaps just using the wrong language

Well I think there is a tension here. C is the language for microcontrollers and the language for high performance.

In ye olden days both groups interests were aligned because speed in C was about working with the machine. Now the UB has been highjacked for speed, that microcontroller that I'm working on, where I know and int will overflow and rely on that is UB so may be optimised out, so I then have to think about what the compiler may do.

I wouldn't say C is the wrong language. I would say there are wrong compilers though.

Re: Everything in C is undefined behavior

#267

Post by dzaima »

account42 wrote: post #174
gpderetta wrote: post #43

Earlier quoted context omitted.

Ex falso quodlibet. Bounding UB would be a nice idea, or at least prohibiting time-traveling UB (and there is an effort in that direction). But properly specifing it is actually hard.

Prohibiting "time-travelling" UB would be horrible as that's a very important mechanism for dead code elimination.

Even if you forbid "time travel", you can still technically optimize many things as if time travel happened anyway - e.g. want to time-travel back to before some memory store? just pretend that the store happened, but then afterwards the previous value was stored back (and no other threads happen to see the intermediate value)!

Only things you need to worry about then are things with actual observable side-effects - volatile, printf and similar - and C23 does note that all observable behavior should happen even if UB follows, and compilers can't generally optimize function calls anyway (e.g. on systems on which you can define custom printf callbacks, you could put an exit(0) in such, and thus make it incorrect to optimize out a printf ever).

Re: Everything in C is undefined behavior

#268

Post by jb1991 »

debugnik wrote: post #265
jb1991 wrote: post #253

Some of the C++ code in this article has not been idiomatic in over a decade, and would be considered a code smell today. The language has evolved into quite a different language than when it was first created. As soon as I saw all of those raw pointers and direct pointer access, it was clear that at least part of this article should be taken with a grain of salt. The other obvious issue with the overall perspective…

I was about to call out that the code is supposed to be C and not C++, but I double checked and I realised it actually says std::atomic , not atomic_int!

Exactly, this is very old C++ on display in this article. It’s certainly not as safe as a language like Rust, but quite a lot of undefended behavior and things that will shoot yourself in the foot have been changed over the last 10 years.

Most C++ today will be immediately obvious and not accidentally mixed up with C.

Re: Everything in C is undefined behavior

#269

Post by veltas »

thomashabets2 wrote: post #188
veltas wrote: post #5

From the ANSI C standard: 3.16 undefined behavior: Behavior, upon use of a nonportable or erroneous program construct, of erroneous data, or of indeterminately valued objects, for which this International Standard imposes no requirements. Permissible undefined behavior ranges from ignoring the situation completely with unpredictable results, to behaving during translation or program execution in a documented manner c…

Author here. I touched on this in the "it's not about optimizations" section. It's not the compiler is out to get you. It's that you told it to do something it cannot express. It's like if you slipped in a word in French, and not being programmed for French, it misheard the word as a false friend in English. The compiler had no way to represent the French word in it's parse tree. So no, it's not overly legalistic. Li…

It's not that your article specifically discusses this aspect, but I think it's an important part of the conversation that's being overlooked by commentators, that we've twisted the original intent of UB and made unnecessary work for ourselves. There's been too much scaremongering about UB that's gone beyond the real concerns. If you only fear UB and don't understand it then you are worse off for trying to write safe C or C++.

Re: Everything in C is undefined behavior

#270

Post by dminik »

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?

If only it was that easy: https://silentsblog.com/2025/04/23/gta-san-andreas-win11-24h...

The real answer is that proponents of languages like C seem to completely disregard the dangers/difficulty of hitting/difficulty of fixing UB. Proponents of languages like Rust overstate it instead. Pointless wars/drama is fun to read and gets clicks.

Post reply on HN