9 ms·
Somewhat unfortunately this is valid behavior according to the standard. Having to go through walls of text in a standard to prevent the compiler from deleting
by vgatherps 4y ago
Somewhat unfortunately this is valid behavior according to the standard. Having to go through walls of text in a standard to prevent the compiler from deleting your security checks because of how you multiplied two integers seems a bit silly.
Having said that I’m of split feelings here. I work in a very performance sensitive industry and on one hand welcomes the ability of compilers to use the knowledge that certain things “can’t happen” to optimize, without me having to always do these optimizations be hand.
On the other hand, there seem to be so many cases like this one where the “undefined behavior code deleter goes brrrrrr” really overextends its usefulness. The “lalalalala standard say I can do this can’t hear you” finger in your ears attitude from compiler maintainers doesn’t help at all either.
I understand that the way much of this works, propagating “poison/impossible values”, can hide the root cause, so you can’t just say “please do the good undefined behavior optimizations but not the bad, so there’s no easy answer. The outcome in the blog post doesn’t feel like a local optimum though, and it’s not the only place I’ve felt that your options are “potentially slow code” or “pray you were perfect enough to not have your program deleted”
- proto_lambda 4y agoThe problem here is that the thing that "can't happen" isn't actually something that can't happen, it's something that isn't allowed to happen according to a many-hundred-page document that approximately nobody reads. It's not something that can be optimised because the compiler can prove it cannot happen, it is allowed to be optimised because the standard says "dear programmer, if you ever make this happen, god help you".
- iforgotpassword 4y agoIt's still braindead and idiotic. Every relevant platform nowadays has well defined overflow for signed ints. A sane C compiler should go with that and base its optimizations on it. GCC has been a pile of garbage in this regard for many years now. Its devs get further removed from reality with every year. Treating signed int overflow as undefined should be hidden behind a flag.
- masklinn 4y agoSigned int overflow being UB is one of the most basic UBs of the language, and what allows generating tight code in loops. This is not new, -fwrapv was introduced in 2003, but it can quite severely impact code quality, if you don’t care, just set that. Then complain that C is slow, because C is a shit language.
- iforgotpassword 4y ago> and what allows generating tight code in loops. How so? How does breaking an if statement the programmer added make the code faster? If they intended the check not to happen/be required, they wouldn't have written it. Let signed int overflow and leave any code that depends on its value alone. So yes maybe make fwrapv the default. > because C is a shit language. Well, it's as low level as it can get before reaching assembly, but why not try reducing the number of foot guns? Sometimes you still need C, and that's not going to go away for the foreseeable future.
- masklinn 4y ago> How does breaking an if statement the programmer added make the code faster? If they intended the check not to happen/be required, they wouldn't have written it. See your problem is that you’re 1. not thinking like a compiler 2. and reasoning on an isolated example The compiler does not “break an if statement”, the compiler uses the UB to limit the range of the input and output, it can then propagate this range analysis to see that the check is dead code, and so removes the dead code. It’s common for users to write unnecessary or redundant checks, even more so because of inlining, and especially macros. If you’re carefully checking for null in every function prologue, and the compiler in-line everything and knows the pointer is non-null, all checks are dead and can be removed. Which is what the compiler does. This reduces the amount of branches (and thus the space needed by the branch predictor), and reduces the amount of code meaning the new inlined function could fall below threshold and itself become a candidate for inlining.
- iforgotpassword 4y ago
- josephcsible 4y agoI think this view is slightly unfair. I think of UB as the compiler saying "when you promised this thing wouldn't happen, I took you at your word. If bad things happen because you lied, they're your fault, not mine."
- proto_lambda 4y agoLying requires intent. This was a mistake, something that humans are well-known for making, and if the compiler is designed to assume otherwise, it borders on useless in the real world.
- eru 4y agoThat's C for you. If you want something saner, use Rust or Haskell or Python or even Java or Go or.. almost any other language that's not C or C++. These days the whole point of C is this Faustian pact with the devil of speed for sanity.
- consp 4y agoWriting Rust and Haskell for sanity is not something I would agree with. Maybe for language characteristics but reading those make me jump out of the window.
- eru 4y agoI have the same issue with Java and Go. (Which I brought up as well.) Yet, they still compare favourably with C in this regard. Almost anything does.
- pca006132 4y agoI think Rust doesn't allow integer overflow either, unless you specifically use the wrapping_* operations. Probably the same kind of thing will also happen to Rust.
- 4y ago
- raverbashing 4y agoExcept this can't happen happens many and many times in practice so maybe it's time the language bureaucrats got off their high horse (but they won't)
- pjmlp 4y agoEven if someone would read all those pages, constraining ourselves to ISO C only, no way that after an year they would still remeber the about 200 UB cases that are documented there. Which is why everyone should adopt static analysis tooling and enable all the warnings that are related to UB, pointer and casts misuses. Many think they know better, it is like those that think builders don't need protection gear at a construction site, it is stuff only for the weak.
- gpderetta 4y agoI think implicitly compiler-added runtime check are a more robust and reliable solution than static analysis. For example for pointer dereferences the compiler should could 0-offset dummy load if the load is not guaranteed to be within a page of the pointer. Or adding abort-on-overflow for math. Or bound checking where possible. It will have a non-trivial cost, but hopefully aggressive optimizations can remove many of these checks (which ironically it is exactly the kind of optimizations people are complaining about) and compilers provide pragmas to disable them when critical. In a way sanitizers are getting there, but they are explicitly marked as for non-production use which is a problem.
- pjmlp 4y agoI agree, but unfortunely that will never happen in most C and C++ circles, just see the heat JF Bastien has been facing for a feature that has been shipping in Windows and Android for the last two years, proven in the battlefield to hardly hinder performance in real use cases. https://isocpp.org/files/papers/P2723R0.html https://isocpp.org/files/papers/P2723R0.html Lots of people telling him it will never fly in production, while their Windows and Android phones are using the code that they say isn't good enough.
- gpderetta 4y agoZero initialization is also one of those features that seems such a low hanging fruit to implement... I'm still moderately optimistic. I suspect that many of these checks will end up being enabled by default on compilers shipped by distros, like stack guards and other forms of hardening.
- Asooka 4y agoBasically, the compiler implements integer addition using an operation that doesn't match the semantics of integer addition in the standard, then hallucinates that it did. That is: 1) The compiler sees an expression like "a += b;" where a and b are signed integers. 2) It emits "add rA rB" in x86 assembly (rA/B being the register a/b is currently in). 3) Technically the machine code emitted does not match the semantics of the source code, since it uses wraparound addition, whereas the C standard says that for the operation to be valid, the values of a and b must be such that no overflow would occur. This is fine however, because the implementation has the freedom to do anything on integer overflow, including just punting the problem to hardware as it did in this case. 4) The compiler proceeds with the rest of the code as if the line above would never overflow. My brother in the machine spirit, you chose to translate my program to a form where integer overflow is defined. The compiler should either a) trap on integer overflow; or b) accept integer overflow. It will be fine if it chooses either a) or b) situationally, i.e. if we have a loop where assuming no overflow is faster, then by all means - add a precondition check and crash the program if it's false, but don't just assume overflow doesn't happen when you explicitly emit code with well-defined overflow semantics. The bigger problem is there is pretty much no way to guard against this. The moment your program is longer than one page you're screwed. You may think all your functions are fine, but then you call something from some library, the compiler does some inlining and suddenly there's an integer overflow where you didn't expect, leading to your bounds check being deleted.
- atoav 4y agoThe hard things about C are knowing all these footguns you are getting yourself into. If our electrical grid was built like this we had no isolation, no fuses, no RCDs and a constant torrent of electrocutions and fires. It is bad engineering.
- fps_doug 4y ago... and people defending the status quo because "you just have to know how electricity works" :-)
- oxff 4y ago> On the other hand, there seem to be so many cases like this one where the “undefined behavior code deleter goes brrrrrr” really overextends its usefulness. I would simply not depend on invoking UB as part of my program's behavior (?).
- masklinn 4y agoAlternatively I would not trust myself with not doing that, which is why I don’t use C.
- eru 4y agoThat's the only way to use C correctly. Alas, it's nearly impossible for a mere mortal to write any non-trivial C code that doesn't have UB.
- pjc50 4y ago"a+b" for signed integer types potentially invokes undefined behavior (overflow). It's a horrendous situation.
- vgatherps 4y agoI don't think I ever claimed that one would or should intentionally invoke UB as part of their program's behavior?
- lilllly 4y agoWe need a -fsane-c Then they can add a #pragma optimize(assumes=no-int-overflow, whatever, etc) to precisely add optimizations when needed and you 'know' its safe.
- throwaway81523 4y agoEveryone wants that, but when asked for a concrete specification they seem to realize that it is harder than it sounds. Look for John Regehr's blog entries about "Friendly C" for an example. The basic problem here is that C is a terrible language. We should just give up on it by now.
- sanxiyn 4y agoI provided the concrete specification. What is hard about it? Get it done already.
- Asooka 4y agoYou can get 99% of the way there with -fno-delete-null-pointer-checks -fno-strict-aliasing -fwrapv . Pretty much every program I've worked on uses those flags, as that's the only way to keep your sanity.
- gpderetta 4y ago-fdwim Next generation of AI powered compilers will try to interpret code at a more abstract level and infer what the programmer was thinking even if they wrote the wrong thing. Everything will work perfectly 100% of the time.
- sanxiyn 4y agoThis already exists. Don't write standard C, avoid it like the plague. Compile with -fno-strict-overflow -fno-strict-aliasing -fno-delete-null-pointer-checks, like I do, like Linux kernel does, and like everyone sane does.
- NohatCoder 4y agoNo, not everyone sane. Rather everyone sane who has been bitten enough by these issues to use such rules. Everyone starts out at -O2, because understanding all the other flags and their implications is super difficult. As long as the insane setting is default, a large percentage of programmers will be using the insane setting. Arguing that they should have flagged their compilations otherwise is about as useful as pointing out that people shouldn't write UB in the first place.