81–90 of 101 posts
Earlier quoted context omitted.
> behave the way the C implementers want them to If you don't please your users, you won't have any users.
It's ironic that I have to tell you of all people this, but many users of C (or at least, backends of compilers targeted by C) do actually want the compiler to aggressively optimize around UB.
Earlier quoted context omitted.
> And yet, C++. By any metric, C++ is one of the most successful programming languages devised by mankind, if not the most successful. What point were you trying to make?
True! But C++ is popular almost entirely because of when (in history/what alternatives existed at the time) and where (on what platforms) it first became available, and how much adoption momentum was created during that era. I think claiming that C++ is successful because of the unintuitive-behavior-causing compiler behaviors/parts of the spec is an extraordinary claim--if that's what you mean, then I disagree. TFA d…
Back in the 80s, I was looking for a way to enhance my C compiler. I looked at Objective-C and C++. There was a newsgroup for each, and each had about the same amount of traffic. I had to pick one.
Objective-C required a license to implement it. I asked AT&T if I needed a license to implement C++, and could I call it C++. AT&T's lawyer laughed and said feel free to do whatever you want.
So that decided it for me. At the time, C++ did not exist on the PC other than the awkward, nearly unusable cfront (which translated C++ to C). At the time, 90% of programming was done on the PC.
I implemented it. It was the first native C++ compiler for the PC. (It is arguable that it was the first native C++ compiler, depending on whether a gcc beta is considered a release.)
The usage of it exploded. The newsgroup traffic for C++ zoomed upwards, and Objective-C interest fell away. C++ built critical mass because of Zortech C++.
Borland dropped their plans for an OOP language and went for Turbo C++. Microsoft also had a secret OOP C language called C*, which was also abandoned in favor of implementing C++.
And the rest is history!
P.S. cfront on the PC was unusable because it was 1) incredibly slow and 2) did not support near/far pointers which was required for the mixed PC memory models.
P.P.S. Bjarne Stroustrup never mentioned any of this in his book "The Design and Evolution of C++".
Earlier quoted context omitted.
Why is that a problem? Inlining and optimization aren't minor aspects of compiling to native code, they are responsible for order-of-magnitude speedups. My point is that it is easy to say "don't remove my code" while looking at a simple single-function example, but in actual compilation huge portions of a function are "dead" after inlining, constant propagation and other optimizations: not talking anything about C-sp…
Apologies for the flippant one liner, You made a good point and deserve more than that. On the one hand, having the optimizer save you from your own bad code is a huge draw, this is my desperate hope with SQL, I can write garbage queries and the optimizer will save me from myself. But... Someone put that code there, spent time and effort to get that machinery into place with the expectation that it is doing something…
int factorial(int x) {
if (x 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.
Earlier quoted context omitted.
Where there is UB in the standard it means that a C compiler is free to define the behavior. So of course, somebody could write a C implementation which does this. See also Fil-C for a perfectly memory safe version of C. So the first sentence makes no sense. But also note that there is an ongoing effort to remove UB from the standard. We have eliminated already about 30% of UB in the core language for the upcoming ve…
C is designed in such a way, that designing a safe compiler without big performance penalties isn't possible. How much Fil-C is slower compared to something like GCC? 2 to 5 times slower?
Earlier quoted context omitted.
Do we know that? I've written "dead" code. It's point was to communicate structure or intent, but it was also still dead . This pattern, in one form or another, crops up a lot IME (in multiple languages, even, with varying abilities to optimize it): if condition that is "always" false: abort with message detailing the circumstances That `if` is "dead", in the sense that the condition is always false. But "dead" somet…
What about assertions that are meant to detect bad hardware? I'd think that's not too uncommon, particularly in shops building their own hardware. Noise on the bus, improper termination, ESD, dirty clock signal, etc. -- there are a million reasons why a bit might flip. I wouldn't want the compiler to optimize "obviously wrong" code out anymore then empty loops.
1. you drop down to assembly.
2. you use functions that are purpose built to be sequence points the optimizer won't optimize through. E.g., in Rust, for the case you mention, `read_volatile`.
In either case, this gives the human the same benefit the code is giving the optimizer: an explicit indication that this code that might appear to be doing nothing isn't.
Earlier quoted context omitted.
> I think this is not really true. Or rather, it depends on the UB you are talking about. I mean, if you're going to argue that a compiler can do anything with any UB, then by all means make that argument. Otherwise, then no, I don't think it's reasonable for a compiler to cause an infinite loop inside a function simply because that function itself doesn't return a value.
When you say "cause", do you mean insert on purpose, or do you mean cause by accident? I could see the latter happening, for example because the compiler doesn't generate a ret if the non-void function doesn't return anything, so control flow falls through to whatever code happens to be next in memory. I'm not aware of any compiler that does that, but it's something I could see happening, and the developers would hav…
https://www.quora.com/What-is-the-most-subtle-bug-you-have-h...
The problem was that the loop itself was altered, rather than that the function returned and then that somehow caused an infinite loop.
> I'm not aware of any compiler that does that, but it's something I could see happening, and the developers would have no reason to "fix" it, because it's perfectly up to spec.
This is where we disagree.
Earlier quoted context omitted.
> I think this is not really true. Or rather, it depends on the UB you are talking about. I mean, if you're going to argue that a compiler can do anything with any UB, then by all means make that argument. Otherwise, then no, I don't think it's reasonable for a compiler to cause an infinite loop inside a function simply because that function itself doesn't return a value.
I am not sure what statement you are responding to. I am certainly not arguing that. I disagree with your claim that "it is practically impossible find a program without UB".
https://people.csail.mit.edu/nickolai/papers/wang-stack.pdf
I submit that that's a small fraction of UB, that much of it would exist at any optimization level.
Earlier quoted context omitted.
I am not sure what statement you are responding to. I am certainly not arguing that. I disagree with your claim that "it is practically impossible find a program without UB".
A study found that, for a particular subset of UB (code that had legal, detectable behavior changes at differing optimization levels), 40% of Debian Wheezy packages exhibited this UB. https://people.csail.mit.edu/nickolai/papers/wang-stack.pdf I submit that that's a small fraction of UB, that much of it would exist at any optimization level.
Earlier quoted context omitted.
Another alternative is that the programmer write their own C compiler and be free of this politics. Maybe I am biased since I am working on exactly such a project, but I have been seeing more and more in-progress compiler implementations for C or C-like languages for the past couple years.
And please provide feedback to WG14. Also please give feedback and file bugs for GCC / clang. There are users of C in the committee and we need your support. Also keeping C implementable for small teams is something that is at risk.