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

Weekend projects: getting silly with C

lcamtuf.substack.com

Post reply on HN
Print view View original

81–90 of 118 posts

Re: Weekend projects: getting silly with C

#81

Post by kazinator »

quietbritishjim wrote: post #29

> The above example will print the value of a, but it won’t be initialized to 123! It certainly could do though. In C, using an uninitialised variable does not mean "whatever that memory happened to have in it before" (although that is a potential result). Instead, it's undefined behaviour, so the compiler can do what it likes. For example, it could well unconditionally initialise that memory to 123. Alternatively, i…

In C, it is only undefined behavior to access an automatic object that has not been initialized.

Static objects are always initialized, so the situation cannot arise.

That leaves dynamic ones, like uninitialized struct members in a malloced structure.

Accessing uninitialized dynamic memory means isn't undefined behavior in C. It results in whatever value is implied by the uninitialized bits. If the type in question has no trap representations, then it cannot fail.

Re: Weekend projects: getting silly with C

#82

Post by kazinator »

uecker wrote: post #31
quietbritishjim wrote: post #29

> The above example will print the value of a, but it won’t be initialized to 123! It certainly could do though. In C, using an uninitialised variable does not mean "whatever that memory happened to have in it before" (although that is a potential result). Instead, it's undefined behaviour, so the compiler can do what it likes. For example, it could well unconditionally initialise that memory to 123. Alternatively, i…

UB can not travel back in time in C. Although it is true that it can affect previous instructions, but that code is reordered or transformed in complicated ways is true even without UB.

If a compiler can determine that some statement is UB, it can treat that as an assertion that the code is unreachable. All other statements which reach only that code and no other are also unreachable.

A compiler's analysis can go backward in time. That is to say, the compiler can build a model of what happens in some section of code over time, and analyze it whichever way it wants.

You cannot go back in time from execution time to translation time, but the translator can follow the code as if it were executing it at translation time.

Re: Weekend projects: getting silly with C

#83

Post by kazinator »

uecker wrote: post #39
ant6n wrote: post #35

Earlier quoted context omitted.

> but that code is reordered or transformed in complicated ways is true even without UB. Without undefined behavior, the compiler emits code that has the behavior defined by the code —- the ordering may be altered, but not the behavior.

Yes, and with undefined behavior, the compiler has to emit code that has the behavior defined by the code up to the operation that has undefined behavior.

That is false. If a compiler determines that some statement has undefined behavior, it can treat it as unreachable, and, transitively, other code before it as unreachable.

  printf("hello\n"); // this doesn't have to print
  x = x / 0;         // because this is effectively a notreached() assertion

Re: Weekend projects: getting silly with C

#84

Post by tialaramex »

uecker wrote: post #57
tialaramex wrote: post #33

Earlier quoted context omitted.

Sure, it's just an opinion. I think the consequences speak very well for themselves.

What consequences?

Because MMIO is made to look like it's really just memory (rather than a technical convenience) C programmers use the MMIO the same way they would the heap memory in the abstract machine. Sometimes the compiler will correctly intuit what needs to actually be emitted, sometimes the hardware they're actually talking to will compensate for what actually happens - other times it just "misbehaves" because this is not memory and so it doesn't behave like memory.

Re: Weekend projects: getting silly with C

#85

Post by eacnamn »

astrange wrote: post #80
tomjakubowski wrote: post #78

Earlier quoted context omitted.

crt0 generally isn't C and isn't subject to C's rules

malloc() can't be implemented in C either because it's defined as doing things (creating new memory objects) there are no lower level mechanisms in C to do.

all malloc is defined to do is to return a pointer to storage of appropriate size and alignment, which can easily be done in pure standard C by defining a static array and chopping it up as needed. that's not a brilliant way of doing that, but achievable without leaving standard C

Re: Weekend projects: getting silly with C

#86

Post by jstimpfle »

kazinator wrote: post #83
uecker wrote: post #39

Earlier quoted context omitted.

Yes, and with undefined behavior, the compiler has to emit code that has the behavior defined by the code up to the operation that has undefined behavior.

That is false. If a compiler determines that some statement has undefined behavior, it can treat it as unreachable, and, transitively, other code before it as unreachable. printf("hello\n"); // this doesn't have to print x = x / 0; // because this is effectively a notreached() assertion

This is in direct contradiction to what uecker says. Can you back up your claim -- for both C and C++? Putting your code in godbolt with -O3 did not remove the print statement for me in either C or C++. But I didn't experiment with different compilers or compiler flags, or more complicated program constructions.

https://godbolt.org/z/8nbbd3jPW

I've often said that I've never noticed any surprising consequences from UB personally. I know I'm on thin ice here and running risk of looking very ignorant. There are a lot of blogposts and comments that spread what seems like FUD from my tiny personal lookout. It just seems hard to come across measureable evidence of actual miscompilations happening in the wild that show crazy unpredictable behaviour -- I would really like to have some of it to even be able to start tallying the practical impact.

And disregarding whatever formulations there are in the standard -- I think we can all agree that insofar compilers don't already do this, they should be fixed to reject programs with an error message should they be able to prove UB statically -- instead of silently producing something else or acting like the code wouldn't exist.

Is there an error in my logic -- is there a reason why this shouldn't be practically possible for compilers to do, just based on how UB is defined? With all the flaws that C has, UB seems like a relatively minor one to me in practice.

Another example: https://godbolt.org/z/b5j99enTn

This is an adaption from the Raymond Chen post, and it seems to actually compile to a "return 1" when compiling with C++ (not with C), at least with the settings I tried. And even the "return 1" for me is understandable given that we actually hit a bug and there are no observeable side-effects before the UB happens. (But again, the compiler should instead be so friendly and emit a diagnostic about what it's doing here, or better return an error).

Un-comment the printf statement and you'll see that the code totally changes. The printf actually happens now. So again, what uecker says about observable effects seems to apply.

Re: Weekend projects: getting silly with C

#87

Post by gpderetta »

uecker wrote: post #70
grumbelbart wrote: post #65

Earlier quoted context omitted.

So maybe we have different definitions of "time travel". But I recall that - if a compiler finds that condition A would lead to UB, it can assume that A is never true - that fact can "backpropagate" to, for example, eliminate comparisons long before the UB. Here is an older discussion: https://softwareengineering.stackexchange.com/q/291548 Is that / will that no longer be true for C23? Or does "time-travel" mean some…

There may be different definitions, but also a lot of incorrect information. Nothing changes with C23 except that we added a note that clarifies that UB can not time-travel. The semantic model in C only requires that observable effects are preserved. Everything else can be changed by the optimizer as long as it does not change those observable effects (known as the "as if" principle). This is generally the basis of m…

I think the clarification is good, probably the amount of optimizations that are prevented by treating volatile and atomics as UB barriers is limited, but as your example show, a lot of very surprising transformations are still allowed.

Unfortunately I don't think there is a good fix for that.

Re: Weekend projects: getting silly with C

#88

Post by kazinator »

jstimpfle wrote: post #86
kazinator wrote: post #83

Earlier quoted context omitted.

That is false. If a compiler determines that some statement has undefined behavior, it can treat it as unreachable, and, transitively, other code before it as unreachable. printf("hello\n"); // this doesn't have to print x = x / 0; // because this is effectively a notreached() assertion

This is in direct contradiction to what uecker says. Can you back up your claim -- for both C and C++? Putting your code in godbolt with -O3 did not remove the print statement for me in either C or C++. But I didn't experiment with different compilers or compiler flags, or more complicated program constructions. https://godbolt.org/z/8nbbd3jPW I've often said that I've never noticed any surprising consequences from U…

The implementation can assume that the program does not perpetrate undefined behavior (other than undefined behavior which the implementation itself defines as a documented extension).

The only way the program can avoid perpetrating undefined behavior in the statement "x = x / 0" is if it does not execute that statement.

Thus, to assume that the program does not invoke undefined behavior is tantamount to assuming that the program does not execute "x = x / 0".

But "x = x / 0" follows printf("hello\n") unconditionally. If the printf is executed, then x = x / 0 will be executed. Therefore if the program does not invoke undefined behavior, it does not execute printf("hello\n") either.

If the program can be assumed not to execute printf("hello\n"), there is no need to generate code for it.

Look at the documentation for GCC's __builtin_unreachable:

> Built-in Function: void __builtin_unreachable (void)

> If control flow reaches the point of the __builtin_unreachable, the program is undefined. It is useful in situations where the compiler cannot deduce the unreachability of the code.

The unreachable code assertion works by invoking undefined behavior!

Re: Weekend projects: getting silly with C

#89

Post by gpderetta »

jstimpfle wrote: post #86
kazinator wrote: post #83

Earlier quoted context omitted.

That is false. If a compiler determines that some statement has undefined behavior, it can treat it as unreachable, and, transitively, other code before it as unreachable. printf("hello\n"); // this doesn't have to print x = x / 0; // because this is effectively a notreached() assertion

This is in direct contradiction to what uecker says. Can you back up your claim -- for both C and C++? Putting your code in godbolt with -O3 did not remove the print statement for me in either C or C++. But I didn't experiment with different compilers or compiler flags, or more complicated program constructions. https://godbolt.org/z/8nbbd3jPW I've often said that I've never noticed any surprising consequences from U…

In this [1] example GCC hoists, even in C mode, a potentially trapping division above a volatile store. If c=0 you get one less side effect than expected before UB (i.e. the division by zero trap). This is arguably a GCC bug if we agree on the new standard interpretation, but it does show that compilers do some unsafe time travelling transformations.

Hoisting the loop invariant div is an important optimization, but in this case I think the compiler could preserve both the optimization and the ordering of the side effects by loop-peeling.

[1] https://godbolt.org/z/ecsdrPa94

Re: Weekend projects: getting silly with C

#90

Post by gpderetta »

kazinator wrote: post #88
jstimpfle wrote: post #86

Earlier quoted context omitted.

This is in direct contradiction to what uecker says. Can you back up your claim -- for both C and C++? Putting your code in godbolt with -O3 did not remove the print statement for me in either C or C++. But I didn't experiment with different compilers or compiler flags, or more complicated program constructions. https://godbolt.org/z/8nbbd3jPW I've often said that I've never noticed any surprising consequences from U…

The implementation can assume that the program does not perpetrate undefined behavior (other than undefined behavior which the implementation itself defines as a documented extension). The only way the program can avoid perpetrating undefined behavior in the statement "x = x / 0" is if it does not execute that statement. Thus, to assume that the program does not invoke undefined behavior is tantamount to assuming tha…

x/0 is not reached if the printf blocks forever, exits or return via an exceptional path (longjmp in C, exceptions in C++). Now specifically standard printf won't longjmp or exit (but glibc one can), but it still can block forever, so the compiler in practice can't hoist UB over opaque function calls.

edit: this is in addition to the guarantees with regard to side effects that uecker says the C standard provides.

Post reply on HN