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

351–360 of 748 posts

Re: Everything in C is undefined behavior

#351

Post by mbrock »

saagarjha wrote: post #336
mbrock wrote: post #258

Earlier quoted context omitted.

Yet the standard does not tell you what the compilers do. Linux works on a wide variety of platforms. It also relies on those platforms behaving predictably with respect to what the standard leaves undefined. This description of ISO UB as a totally insane wonderland of random, malevolent semantics just doesn't describe reality.

Up until the compilers do something to your code that you don’t understand.

yeah then I have to learn how it works and what it assumes and how I can control it and maybe switch to a more well behaved compiler if it's truly insane

Re: Everything in C is undefined behavior

#353

Post by JonChesterfield »

Well, you can't write malloc in conforming C, which hurts rather more than remembering to write bitcast as memcpy on char pointers.

Doesn't matter though because you aren't writing standards conforming C. You're writing whatever dialect your compilers support, and that's probably (module bugs) much better behaved than the spec suggests.

Or you're writing C++ and way more exposed to the adversarial-and-benevolent compiler experience.

The type aliasing rules are the only ones that routinely cause me much annoyance in C and there's always a workaround, whether if it's the launder intrinsic used to implement C++, the may_alias attribute or in extremis dropping into asm. So they're a nuisance not a blocker.

Re: Everything in C is undefined behavior

#354

Post by mbrock »

saagarjha wrote: post #350
mbrock wrote: post #157

Earlier quoted context omitted.

undefined behavior is the behavior of code patterns "for which this International Standard imposes no requirements" and the behavior is in fact almost always predictable and agreed upon by compiler vendors and the users of the language, which is why you are able to use programs that rely on undefined behavior probably every single second you are using the computer edit: for example I'm typing this into Safari which m…

It matters when your JSC JIT is full of security holes

ok what's the alternative?

Re: Everything in C is undefined behavior

#355

Post by imtringued »

indigo945 wrote: post #308
crote wrote: post #303

Earlier quoted context omitted.

The problem is that the function call as a whole is UB. Having the original example compile to the equivalent of volatile int x; int a = x; int b = x; printf("%x %d\n", a, b); is equally valid as volatile int x; int a = x; int b = x; printf("%x %d\n", b, a); , and neither needs to have the same output as your proposed fix. C could've specified something like "arguments are evaluated left-to-right" or "if two argument…

Not only is "arguments are evaluated left-to-right" less easy to formalize than you think, it would also make all C code run slower, because the compiler would no longer be able to interleave computations for more efficient pipelining. The same goes for "expression is [only evaluated once]/[always evaluated twice]". Of course the developer is navigating a minefield every time they use volatile, that's why it's called…

Your argument makes no sense since the developer is expected to perform manual sequencing. Correctly written UB free code cannot be interleaved either.

All you've achieved is that the standard C function call syntax can no longer be used as is.

Re: Everything in C is undefined behavior

#356

Post by JonChesterfield »

mbrock wrote: post #231
simonask wrote: post #131

Earlier quoted context omitted.

Intuitively yes - the program will be compiled as if B-inputs are never passed to the program, and that can include eliminating code that tries to detect B-inputs.

This is a description of an imaginary compiler, evoked by the ANSI/ISO standards documents, which has never existed and will never exist. To understand what the program will do, you just have to understand the compiler behavior on your target platforms. A helpful intuition pump is: imagine the ANSI/ISO specifications simply do not exist; now what? Well, you just continue your engineering practice, the way you would f…

Not imaginary. Eliding checks on nullptr and integer overflow were both implemented, shipped, miscompiled the linux kernel and grew flags to disable them. I expect there are more if one goes looking.

Re: Everything in C is undefined behavior

#358

Post by saagarjha »

lelanthran wrote: post #340
saagarjha wrote: post #322

Earlier quoted context omitted.

Turning undefined behavior into implementation defined behavior is rarely a fix, though.

It's a fix that removes the most pointy part of UB. "Going past the end of the array results in addressing arbitrary values" I can live with. "Going past the end of an array results in anything happening" is a hard sell.

I think it’s a really easy sell, actually: if you go past the end of the array far enough you end up accessing the stack which includes parts of the program like “where does this function return to” or “what is the index used to perform this access” or “there is no page mapped there”. None of these are arbitrary values.
Post reply on HN