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

121–130 of 748 posts

Re: Everything in C is undefined behavior

#121

Post by dwattttt »

dmitrygr wrote: post #73
raphlinus wrote: post #44

Earlier quoted context omitted.

I'm not assuming anything about bit representations. In this case, the spec language is quite clear and unambiguous. 6.3.2.3 paragraph 7: A pointer to an object type may be converted to a pointer to a different object type. If the resulting pointer is not correctly aligned[footnote 68]) for the referenced type, the behavior is undefined. Otherwise, when converted back again, the result shall compare equal to the orig…

I do not see there a promise that the cast will produce an invalid pointer, nor anything prohibiting the compiler from rounding the pointer down, thus producing a valid one. “Converted” does not require bit copy. I don’t see how this interpretation is against any section of the spec.

I also do not see any requirement in the quoted text that the casted pointer be dereferenced before noting "the behavior is undefined".

In practice performing a cast doesn't really do much until you dereference, but without a carve out in the spec, it does really mean "the behavior is undefined".

Re: Everything in C is undefined behavior

#122

Post by simonask »

akiarie wrote: post #110

C is still, by far, the simplest language that we have. Although many newer languages are safer (with the exclusion of Rust, primarily by being slower) the same kinds of issues that are there in C are there in these languages, their effects are just harder to see. People complain about C as though they know how to fix it.

C is not a simple language in the sense that writing software in C is simple, and I think that's the only useful way to understand the word "simple" in this context.

Brainfuck is "simple" by any other definition as well, but that's not a useful quality.

Re: Everything in C is undefined behavior

#124

Post by codeflo »

> The compiler, and really the underlying hardware too, is playing a game of telephone with your UB intentions.

The part about hardware is wrong BTW. In all the cases about null pointers and out-of-bounds access and integer overflow and whatnot, the hardware semantics are clearly defined, and the assembler code does exactly what is written. The way modern compilers act on your code makes C less safe than assembler in that sense.

Re: Everything in C is undefined behavior

#125

Post by account42 »

beeforpork wrote: post #106

The UB in unaligned pointers is even worse: an unaligned pointer in itself is UB, not only an access to it. So even implicit casting a void*v to an int*i (like 'i=v' in C or 'f(v)' when f() accepts an int*) is UB if the cast pointer is not aligned to int. It is important to understand that this is a C level problem: if you have UB in your C program, then your C program is broken, i.e., it is formally invalid and wron…

Which is totally fine and expected for any decent programmer. Casting pointers is clearly here be dragons territory.

Re: Everything in C is undefined behavior

#126

Post by elch »

ErroneousBosh wrote: post #116
Ygg2 wrote: post #85

Earlier quoted context omitted.

> -Acceptance: "Just dont write UB." Just switch to a saner language. And before I get attacked for being a Rust shill, I meant Java :P The bar is so low it's floating near the center of the Earth.

Okay, so Java compiles to machine code now? Because the last time I looked it appeared to need some godawful slow bytecode interpreter that took up thousands of kilobytes of RAM.

If you don't like JIT/JVM there's GraalVM Native Image.

https://www.graalvm.org/latest/reference-manual/native-image...

In the past you could use e.g. Excelsior JET.

Re: Everything in C is undefined behavior

#127

Post by maple3142 »

Is this a correct understanding of UB in C? A program P has a set of inputs A that do not trigger UB, and a complementary set of inputs B that do trigger UB. A correct compiler compiles P into an executable P'. For all inputs in A, P' should behave the same as P. However, for any input in B, the is absolutely no requirements on the behavior of P'.

Re: Everything in C is undefined behavior

#128

Post by pjc50 »

layer8 wrote: post #107
Ygg2 wrote: post #87

Earlier quoted context omitted.

Except in C, validation of user input can in itself be an exploit vector.

That’s true in other languages as well. Any programmatic task can end up being an exploit vector.

No? That's the whole point of formal verification?

You can even kind of retrofit this to C. The classic example is "sel4". You just need a set of proofs that the code doesn't trigger UB. This ends up being much larger and more complicated than the C itself.

Re: Everything in C is undefined behavior

#129

Post by mbel »

tovej wrote: post #118
beeforpork wrote: post #106

The UB in unaligned pointers is even worse: an unaligned pointer in itself is UB, not only an access to it. So even implicit casting a void*v to an int*i (like 'i=v' in C or 'f(v)' when f() accepts an int*) is UB if the cast pointer is not aligned to int. It is important to understand that this is a C level problem: if you have UB in your C program, then your C program is broken, i.e., it is formally invalid and wron…

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.

Unless your code targets some exotic architecture, like idk x86.

Re: Everything in C is undefined behavior

#130

Post by account42 »

greysphere wrote: post #51

The examples aren't really undefined behavior. They are examples that could become UB based on input/circumstances. Which if you are going to be that generous, every function call is UB because it could exceed stack space. Which is basically true in any language (up to the equivalent def of UB in that language). I feel like c has enough actual rough edges that deserve attention that sensationalism like this muddies f…

Yes, this article is pretty much the definition of FUD.
Post reply on HN