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

C and C++ Aren't Future Proof

blog.regehr.org

Post reply on HN
Print view View original

81–90 of 108 posts

Re: C and C++ Aren't Future Proof

#81

Post by csense »

keeperofdakeys wrote: post #16
pkaler wrote: post #5

> This propensity for today’s working programs to be broken tomorrow is what I mean when I say these languages are not future proof. 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 langu…

For most large projects, you usually standardise the compilation environment for a specific release. Any issues for a newer version would be fixed when you make a newer release of your software. Especially for anything that is safety critical, like satellites or spaceships.

The software world does not solely consist of large, safety-critical projects.

Picture a single person or small team releasing an open-source project, it generates little developer interest and a community fails to start, and the original author(s) move on.

Fast forward 5 years or more. The code's floating around the internet, but nobody's left who understands it well enough to explain why it breaks with a modern toolchain. Requiring people to use a compiler -- and possibly an entire operating system -- of that age will deter people significantly from using that project.

Re: C and C++ Aren't Future Proof

#82

Post by jbert »

I don't see how this issue is specific to C/C++.

Don't all languages have "don't do that" corners, even if they are just bugs in the current versions of the compilers/interpreters?

C and C++ at least tell you where some of these are, so actually the situation is better?

Re: C and C++ Aren't Future Proof

#83

Post by mukundmr »

haberman wrote: post #32

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. 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…

Use cpplint, -Werror -Wall and use the Clang compiler toolchain. It has the best compiler time warnings out there. At the end of the day, the toolchains are getting better at error deduction. This problem will not be solved at the toolchain or language level, but patches for specific toolchains have always been the norm for any portable C++ or C library. C+11 removes dependency on poorly written libraries as well by moving many things to the std library.

Re: C and C++ Aren't Future Proof

#84

Post by ge0rg »

The problem with smart compilers is indeed how they break existing (naive) code, optimizing away things like "assert(len + 100 > len)" [1]

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.

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.

[1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475

[2] http://stackoverflow.com/questions/3944505/detecting-signed-...

Re: C and C++ Aren't Future Proof

#85

Post by shaurz »

dragontamer wrote: post #60
munin wrote: post #17

Earlier quoted context omitted.

Ostensibly, a platform like Java or Rust is supposed to abstract stuff like the memory model. I haven't written a lot of Java code, especially not Java code that runs on many different native system / VMs, but from my perspective of blissful ignorance, it seems to have done the job? Same with other high-level VM based languages like Python...

Python is not future proof. There are undefined sequences even in Python, where Jython and CPython output different programs.

Not to mention the GIL...

Re: C and C++ Aren't Future Proof

#86

Post by ygra »

ge0rg wrote: post #84

The problem with smart compilers is indeed how they break existing (naive) code, optimizing away things like "assert(len + 100 > len)" [1] 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. Therefore, I hope that option 3 proposed by the author (change…

I don't really see how that's a problem with the compilers instead of with the language.

Re: C and C++ Aren't Future Proof

#87

Post by ygra »

pcwalton wrote: post #62
mikeash wrote: post #25

Earlier quoted context omitted.

You certainly could define some basic things to make the language safer. For example, make variables always be initialized to zero if not explicitly initialized, and force accessing beyond the bounds of an array to be a fault rather than undefined behavior.

Initializing variables to zero doesn't buy you much in terms of safety, IMHO. The value 0 isn't necessarily any more valid than an arbitrary value. Better is Java/ML/Haskell's rule whereby variables must be explicitly initialized before use. This can be implemented with a simple compiler pass.

At least the value 0 is always the same and doesn't subtly change from one invocation to the next or from one machine to the next. It certainly helps in making programs more robust, even if there is still a problem at code level.

Re: C and C++ Aren't Future Proof

#89

Post by barrkel »

pkaler wrote: post #12
mjn wrote: post #9

Earlier quoted context omitted.

The particular kind of not-future-proofness he has in mind seems pretty practically important: code that relies on this undefined behavior often suffers from exploitable security holes. Just because computing is complex doesn't mean you have a free pass if you shoot yourself (or your customers) in the foot the same way the previous 100 folks did. If it happens enough, it becomes prudent to do something about it, like…

> His suggestion #3, that the standards should define more of the commonly used behavior and leave less of it undefined, wouldn't even require C programmers to do anything about it themselves. I've written Windows, Mac, Linux, Xbox, PlayStation, PSP, iOS, and Android code. The memory model is subtly different for each platform. I just don't think you can define certain behaviour and have that work across disparate pl…

You underestimate how much undefined behaviour is in typical C programs and how little of it is yet taken advantage of by compilers.

The compilers are now starting to fairly radically rewrite the original code in ways the author would not recognize, simply because of some undefined behaviour exists within the code. You need to be increasingly language lawyerly to avoid the compiler outsmarting you, almost as if it was a hostile opponent.

The read of an uninitialized variable in the article was a good example.

The problem is that programmers have a mental model of how the C they write turns into machine code, and that model is increasingly out of date in the search for more performance. The compiler is becoming less predictable, in precisely the way that we argue against "sufficiently smart compilers" in the past for languages at a higher level than C - that you wouldn't be able to predict when the smart compiler was smart enough to optimize your high-level construct. Now you're increasingly unable to predict what the compiler will turn your code into, unless you have a deeper understanding of the rules.

Re: C and C++ Aren't Future Proof

#90

Post by Peaker »

pkaler wrote: post #12
mjn wrote: post #9

Earlier quoted context omitted.

The particular kind of not-future-proofness he has in mind seems pretty practically important: code that relies on this undefined behavior often suffers from exploitable security holes. Just because computing is complex doesn't mean you have a free pass if you shoot yourself (or your customers) in the foot the same way the previous 100 folks did. If it happens enough, it becomes prudent to do something about it, like…

> His suggestion #3, that the standards should define more of the commonly used behavior and leave less of it undefined, wouldn't even require C programmers to do anything about it themselves. I've written Windows, Mac, Linux, Xbox, PlayStation, PSP, iOS, and Android code. The memory model is subtly different for each platform. I just don't think you can define certain behaviour and have that work across disparate pl…

The guy behind "Embedded in Academia" knows quite a bit about the memory models supported by C, and had done some marvelous work regarding the testing of C compilers, C code and undefined behavior. If he claims it is possible to improve the situation and leave less behavior undefined, he's most probably right.
Post reply on HN