> This propensity for today’s working programs to be broken tomorrow is what I mean when I say these languages are not future proof.<p>It doesn't matter. This is not how programming works in the real world. In the real world, you write the most correct program you can under time pressure. A new compiler, operating system, or platform arrives that exposes a bug. You fix it and you move on. It doesn't matter if the language is future proof or not. The process is similar for any complex program.<p>The blog's name is "Embedded in Academia" and this is perfectly valid viewpoint for someone in academia to take. And people in academia should research towards building more robust tools and languages. But it really is not going to matter in the real world. Languages and platforms will always not be future proof because computing is complex.
I think there is an important point here, which is that C and C++ compilers have let us get away with a lot of undefined behavior for a long time, and that there hasn't been a lot of tooling to help avoid it nor a culture that stresses the long-term danger of depending on it.<p>I can speak as someone who has been programming in C and C++ for over ten years, but only in the last few years became aware of this issue and started taking it seriously. Five years ago I would do things like cast function pointers to void-pointer and back, or calculate addresses that were outside the bounds of any allocated object and compare against them, all without really even realizing I was doing something wrong.<p>I don't think this will spell doom-and-gloom for C and C++ though. I think a few things will happen.<p>First of all, the compiler people are walking a fine line; yes, they are breaking code that relies on undefined behavior, but they often avoid breaking too much. For example, I've had it explained to me that at least for the time being, gcc's LTO avoids breaking any programs that would work when compiled with a traditional linker. In addition, they often provide switches that preserve traditional semantics for non-compliant code that needs it (like -fno-strict-aliasing and -fwrapv).<p>Secondly, I believe that tooling will get better, and rather than ignoring the warnings I believe that people's general awareness of this issue will raise, as well as knowledge of standard-compliant ways of working around common patterns of undefined behavior. For example, it's often easy to avoid aliasing problems by using memcpy(), and this can usually be optimized away.<p>Thirdly, I expect that the standard may begin to define some of this behavior. For example, I think that non-twos-complement systems are exceedingly rare these days; I wouldn't be surprised if a future version of the standard defines unsigned->signed conversions accordingly.
This caught my eye "Program analyzers that warn about these problems are likely to lose users."<p>For me, this is perhaps the biggest issue raised in this article, as static and dynamic analysis tools become more ubiquitous we should be learning to fix the issues that they raise, not ignore them.<p>I remember a while ago (2004 or 5) interviewing a college-hire candidate, I had asked about working with others and we had gotten to talking about code review - the candidate was passionate about how code review had helped with a group project he worked on, but every single example he gave of a a bug found by code review was something that -Wall would have found...<p>The same applies to static analysis - let the machines do the work that they can do, that leaves the humans to get on with the work that the machines can't do (yet!)
The problem with smart compilers is indeed how they break existing (naive) code, optimizing away things like "assert(len + 100 > len)" [1]<p>Making a correct overflow check in C/C++ is not just not straightforward, it is overy complicated even for experienced developers [2]. This is IMHO inacceptable for a thing that is required often in a security context.<p>Therefore, I hope that option 3 proposed by the author (change of the C/C++ standard to define the correct behavior at for least integer overflows) will be adopted. However, this probably will not happen for a long time, leaving us with security holes all over the net.<p>[1] <a href="http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475" rel="nofollow">http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475</a><p>[2] <a href="http://stackoverflow.com/questions/3944505/detecting-signed-overflow-in-c-c" rel="nofollow">http://stackoverflow.com/questions/3944505/detecting-signed-...</a>
C and C++ indeed aren't future-proof, but it's not juste because of undefined behavior, it's by remaining stuck firmly in the 1960's in terms of programming style.<p>C++11 added many changes intended for "do-it-yourself" crowd, like auto, new function syntax, lambdas. It didn't add much in terms of "let the compiler do the work for me" crowd (one notable exception being variadic templates, something that was in my own XL programming language since 2000). In C++, you are still supposed to do the boring work yourself.<p>For example, C++11 still lack anything that would let you build solid reflexion and introspection, or write a good garbage collector that doesn't need to scan tons of non-pointers.<p>If you want to extend C++, it's just too hard. C++11 managed to add complexity to the most inanely complex syntax of all modern programming languages. Building any useful extension on top of C++, like Qt's slots and signals, is exceedingly difficult. By contrast, Lisp has practically no syntactic construct and is future proof. My own XL has exactly 8 syntactic elements in the parse tree.<p>So in my opinion, C and C++ are already left behind for a lot of application development these days because they lack a built-in way to evolve. If you are curious, this is a topic I explore more in depth under the "Concept programming" moniker, e.g. <a href="http://xlr.sourceforge.net/Concept%20Programming%20Presentation.pdf" rel="nofollow">http://xlr.sourceforge.net/Concept%20Programming%20Presentat...</a>.
A side note I took away from this post is the existence of Frama-C, which appears to be a quite nice, open-source analyzer: <a href="http://frama-c.com/" rel="nofollow">http://frama-c.com/</a>
So far I doubt C++ is going anywhere - it's here to stay. When the usage of such languages as Rust will gain more traction up to the point that high performance games engines will be written in it, one could start saying that C++ is being pushed out. But it's really somewhere in the future.
Hey, don't lump C++ in with this. If you write code in the STL weenie style or the Pretend It's Java style there aren't any idioms I know of that would ever violate the rules he mentions (out-of-range pointers, signed overflow, invalid aliasing). I don't do those things and the C++ programmers I work with don't do those things, at least not habitually. I don't see violations of undefined behavior rules, or the use of idioms that come close to it, very often in our code. Not nearly as often as the sort of mundane errors that no language can prevent.<p>These are not problems of a language per se, but the original sins of neo-vaxocentrism and confusing "I understand how this might work, at some random abstraction layer" and "I can depend on what happens when I do something stupid". Free your mind of these and the rest will follow.<p>These low-level bit banging errors are vastly less common than shared-memory concurrency issues, which as far as I can tell are endemic to all code that attempts shared-memory concurrency, in any language. If you want to have an axe to grind about languages that aren't future proof, look there.
If all people started writing code with more RAII and Smart Pointers this would be a better world.<p>Talking about C, well... it's unsafe by nature, let's face it.
It will exist as long as there are people porting C to other architectures!<p>C is there since 1972, it is one of the most widely used programming languages of all time and there are very few computer architectures for which a C compiler does not exist. Many later languages have borrowed directly or indirectly from C, including C#, D, Go, Java, JavaScript, Limbo, LPC, Perl, PHP, Python, and Unix's C shell.
Nothing is future proof - don't worry. We have only been programming for the last 60 years. C has endured 40 years out of that. That is no guarantee that it will endure further. But the point is programming practices has not drastically changed during the course of these years. As and when a disruption occurs there, almost all our current tools shall be rendered obselete.
I don't see how this issue is specific to C/C++.<p>Don't all languages have "don't do that" corners, even if they are just bugs in the current versions of the compilers/interpreters?<p>C and C++ at least <i>tell</i> you where some of these are, so actually the situation is better?
People use C/C++ like you ride on the streets and freeway - the sign says 65mph max, yet everyone else is on 70. Just don't go too much over it.<p>Laws are the be broken, and C/C++ is the wild west in this respect - cowboy programming is welcomed.<p>And I love it :)
Wow, C and C++ have undefined behavior? I bet nobody knows that unless... they took an undergrad comp sci class.<p>Why is this on HN?<p>Use the right tool for the job. Sometimes that C or C++, sometimes it's not.