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

What every compiler writer should know about programmers (2015) [pdf]

complang.tuwien.ac.at

Post reply on HN
Print view View original

51–60 of 101 posts

Re: What every compiler writer should know about programmers (2015) [pdf]

#51

Post by zephen »

deathanatos wrote: post #19
zephen wrote: post #3

Here's a cogent argument that any decision by compiler writers that they can do whatever they wish whenever they encounter an "undefined behavior" construct is rubbish: https://www.yodaiken.com/2021/05/19/undefined-behavior-in-c-... And here's a cautionary tale of how a compiler writer doing whatever they wish once they encounter undefined behavior makes debugging intractable: https://www.quora.com/What-is-the-most-s…

> undefined behavior makes debugging intractable: By their own admission, the compiler warns about the UB. "-Wanal"¹, as some call it, makes it an error. Under UBSan the program aborts with: code.cpp:4:6: runtime error: execution reached the end of a value-returning function without returning a value … "intractable"? ¹a humorous name for -Wextra -Wall -Werror

Not everybody has full control over their environment.

The -Werror flag is not even religiously used for building, e.g. the linux kernel, and -Wextra can introduce a lot of extraneous garbage.

This will often make it easier (though still difficult) to winnow the program down to a smaller example, as that person did, rather than to enable everything and spend weeks debugging stuff that isn't the actual problem.

Re: What every compiler writer should know about programmers (2015) [pdf]

#52

Post by Gibbon1 »

WalterBright wrote: post #8
Joker_vD wrote: post #5

In the end it all boils to a very simple argument. The C programmers want the C compilers to behave one way, the C implementers want the C compilers to behave the other way. Since the power structure is what it is — the C implementers are the ones who write the C standard and are the ones who actually get to implement the C compilers — the C compilers do, and will, behave the way the C implementers want them to. In t…

> behave the way the C implementers want them to If you don't please your users, you won't have any users.

Consider that most programmers have long since fled for other languages.

Re: What every compiler writer should know about programmers (2015) [pdf]

#53

Post by muldvarp »

A C compiler is a relatively simple program (especially if you don't want any optimizations based on undefined behavior). If a large part of the userbase is unhappy with the way most modern C compilers work, they could easily write a "friendly"/"boring" C compiler.

Re: What every compiler writer should know about programmers (2015) [pdf]

#54

Post by zephen »

Joker_vD wrote: post #4
zephen wrote: post #3

Here's a cogent argument that any decision by compiler writers that they can do whatever they wish whenever they encounter an "undefined behavior" construct is rubbish: https://www.yodaiken.com/2021/05/19/undefined-behavior-in-c-... And here's a cautionary tale of how a compiler writer doing whatever they wish once they encounter undefined behavior makes debugging intractable: https://www.quora.com/What-is-the-most-s…

Wow, that's a very torturous reading of a specific line in a standard. And it doesn't really matter what Yodaiken thinks this line means because standard is written by C implementers for (mostly) C implementers. So if C compile writers think this line means they can use UB for optimizing purposes, then that's what it means. Yeah, I know it breaks the common illusion among the C programmers that they're "close to the…

> Wow, that's a very torturous reading of a specific line in a standard.

It's actually a much more torturous reading to say "if any line in the program contains undefined behavior (such as the example given in the standard, integer overflow), then it's OK for the compiler to treat the entire program as garbage and create any behavior whatsoever in the executable."

Which is exactly what had been claimed, that he was addressing.

Re: What every compiler writer should know about programmers (2015) [pdf]

#55

Post by zephen »

fluoridation wrote: post #30
somat wrote: post #25

Earlier quoted context omitted.

I find where the argument gets lost is when undefined behavior is assumed to be exactly that, an invariant. That is to say, I find "could not happen" the most bizarre reading to make when optimizing around undefined behavior "whatever the machine does" makes sense, as does "we don't know". But "could not happen???" if it could not happen the spec would have said "could not happen" instead the spec does not know what…

Some behaviors are left unspecified instead of undefined, which allows each implementation to choose whatever behavior is convenient, such as, as you put it, whatever the hardware does. IIRC this is the case in C for modulo with both negative operands. I would imagine that the standard writers choose one or the other depending on whether the behavior is useful for optimizations. There's also the matter that if a beha…

But even integer overflow is undefined.

It's practically impossible to find a program without UB.

Re: What every compiler writer should know about programmers (2015) [pdf]

#56

Post by muldvarp »

rurban wrote: post #12

This was 2015, and we still have no -Wdeadcode, warning of removal of "dead code", ie what compilers think of dead code. If a program writer writes code, it is never dead. It is written. It had purpose. If the compiler thinks this is wrong, it needs to warn about it. The only dead code is generated code by macros.

I'd love for you to write a C compiler that does this and then realize how much dead code there is in your C projects.

Re: What every compiler writer should know about programmers (2015) [pdf]

#57

Post by muldvarp »

duped wrote: post #43
BeeOnRope wrote: post #14

Earlier quoted context omitted.

Dead code is extremely common in C or C++ after inlining, other optimizations.

If dead code (1) is common in your codebase then your code base is missing heaps of refactors (1) "dead" meaning unused types, unreachable branches

Not really, no. If you use a regex library it is very likely that 80% of that code is effectively dead code.

Re: What every compiler writer should know about programmers (2015) [pdf]

#58

Post by uecker »

zephen wrote: post #55
fluoridation wrote: post #30

Earlier quoted context omitted.

Some behaviors are left unspecified instead of undefined, which allows each implementation to choose whatever behavior is convenient, such as, as you put it, whatever the hardware does. IIRC this is the case in C for modulo with both negative operands. I would imagine that the standard writers choose one or the other depending on whether the behavior is useful for optimizations. There's also the matter that if a beha…

But even integer overflow is undefined. It's practically impossible to find a program without UB.

I think this is not really true. Or rather, it depends on the UB you are talking about. There is UB which is simply UB because it is out-of-scope for the C standard, and there is UB such as signed integer overflow that can cause issues. It is realistic to deal with the later, e.g. by converting them to traps with a compiler flags.

Re: What every compiler writer should know about programmers (2015) [pdf]

#59

Post by uecker »

zephen wrote: post #51
deathanatos wrote: post #19

Earlier quoted context omitted.

> undefined behavior makes debugging intractable: By their own admission, the compiler warns about the UB. "-Wanal"¹, as some call it, makes it an error. Under UBSan the program aborts with: code.cpp:4:6: runtime error: execution reached the end of a value-returning function without returning a value … "intractable"? ¹a humorous name for -Wextra -Wall -Werror

Not everybody has full control over their environment. The -Werror flag is not even religiously used for building, e.g. the linux kernel, and -Wextra can introduce a lot of extraneous garbage. This will often make it easier (though still difficult) to winnow the program down to a smaller example, as that person did, rather than to enable everything and spend weeks debugging stuff that isn't the actual problem.

Yes, this is the funny thing. People do not want to spend time using a stricter language as already supported by C compilers using compiler flags because "it is waste of time" while others argue that we need to switch to much stricter languages. Both positions can not be true at the same time.

Re: What every compiler writer should know about programmers (2015) [pdf]

#60

Post by zephen »

AlotOfReading wrote: post #13
Joker_vD wrote: post #4

Earlier quoted context omitted.

Wow, that's a very torturous reading of a specific line in a standard. And it doesn't really matter what Yodaiken thinks this line means because standard is written by C implementers for (mostly) C implementers. So if C compile writers think this line means they can use UB for optimizing purposes, then that's what it means. Yeah, I know it breaks the common illusion among the C programmers that they're "close to the…

Compiler writers are free to make whatever intentional choices they want and document them. UB is especially nasty compared to other kinds of bugs because implementors can't/refuse to commit to any specific behavior, not because they've chosen the wrong behaviors.

> Compiler writers are free to make whatever intentional choices they want and document them.

Sure, but it's unlikely it's an intentional choice to cause an infinite loop simply because your boolean function didn't return a boolean.

Post reply on HN