Let’s sunset C/C++
trevorjim.com
Let’s sunset C/C++
1–10 of 137 posts
Re: Let’s sunset C/C++
#2Absurdly absurd ideas and ramblings. I suppose we can write our "safe languages" in "safe languages" then we'll never have need of really programming anything ourselves. We can simply pat together what ever is "safe" for us to do in our little play sandbox and act like we're adults who understand the problems faced when programming in "real" languages.
This would be similar to replacing all automobiles with stuffed animals because, who in the world ever heard of stuffed animals getting into pile-up wreaks on the freeway and causing death misery and misfortune.
Re: Let’s sunset C/C++
#3C still got a right to exist even in the very sensitive mission-critical environments, as long as MISRA requirements are followed (and, the good thing is that they can be automatically enforced).
Re: Let’s sunset C/C++
#4Absurdly absurd ideas and ramblings. I suppose we can write our "safe languages" in "safe languages" then we'll never have need of really programming anything ourselves. We can simply pat together what ever is "safe" for us to do in our little play sandbox and act like we're adults who understand the problems faced when programming in "real" languages. This would be similar to replacing all automobiles with stuffed a…
Rule 20.4 (required): Dynamic heap memory allocation shall not be used.
Good luck writing misra-compliant web browser.
And yes, safe languages can be written in safe languages. See rust and servo.
Re: Let’s sunset C/C++
#5This is quite ignorant of why C/C++ is used.
It is used for that exact memory control and access that this article demonizes so that we can have efficient and thought out systems.
When those systems aren't well thought out or secure you have security issues. C/C++ lets you build a wobbly treehouse _and_ a secure fortress. It is up to the developer which one is made...
Re: Let’s sunset C/C++
#6Absurdly absurd ideas and ramblings. I suppose we can write our "safe languages" in "safe languages" then we'll never have need of really programming anything ourselves. We can simply pat together what ever is "safe" for us to do in our little play sandbox and act like we're adults who understand the problems faced when programming in "real" languages. This would be similar to replacing all automobiles with stuffed a…
Rule 20.4 (required): Dynamic heap memory allocation shall not be used. Good luck writing misra-compliant web browser. And yes, safe languages can be written in safe languages. See rust and servo.
> Good luck writing misra-compliant web browser.
I'd be delighted to see one. Statically pre-allocating a large continuous chunk of memory for the whole browser process lifetime would have been great.
Re: Let’s sunset C/C++
#7This is quite ignorant of why C/C++ is used. It is used for that exact memory control and access that this article demonizes so that we can have efficient and thought out systems. When those systems aren't well thought out or secure you have security issues. C/C++ lets you build a wobbly treehouse _and_ a secure fortress. It is up to the developer which one is made...
A place where your reasoning breaks down is when one comes to define "the developer".
There are a few legendary developers in the world I would trust to write secure C/C++. Others may be able to do so, by luck.
Would I trust an organization of 2000 people all developing the same large code base? I know there are processes that can be adopted, such as using clever static analysis tools and rigorous review by security professionals.
But time and time again, the community says "Yay, we've invented X, this makes a huge class of security bugs obsolete". Then Y comes along and opens the playing field again. (e.g, X=Data execution prevention, Y=Return oriented programming).
This keeps happening. It takes some arrogance to believe that a safe large system can be built in an unsafe language, these days.
Re: Let’s sunset C/C++
#8This is quite ignorant of why C/C++ is used. It is used for that exact memory control and access that this article demonizes so that we can have efficient and thought out systems. When those systems aren't well thought out or secure you have security issues. C/C++ lets you build a wobbly treehouse _and_ a secure fortress. It is up to the developer which one is made...
[deleted]
Re: Let’s sunset C/C++
#9Earlier quoted context omitted.
Rule 20.4 (required): Dynamic heap memory allocation shall not be used. Good luck writing misra-compliant web browser. And yes, safe languages can be written in safe languages. See rust and servo.
> Good luck writing misra-compliant web browser. I'd be delighted to see one. Statically pre-allocating a large continuous chunk of memory for the whole browser process lifetime would have been great.
And then, what do you do with that chunk? Since the amount of memory you need depends on the website (e.g. some might need memory for a canvas, others might display large tables, etc.), presumably you take parts of it and allocate them for the various tasks you need to do? So you just write your own dynamic memory allocator.
Re: Let’s sunset C/C++
#10Absurdly absurd ideas and ramblings. I suppose we can write our "safe languages" in "safe languages" then we'll never have need of really programming anything ourselves. We can simply pat together what ever is "safe" for us to do in our little play sandbox and act like we're adults who understand the problems faced when programming in "real" languages. This would be similar to replacing all automobiles with stuffed a…
Rule 20.4 (required): Dynamic heap memory allocation shall not be used. Good luck writing misra-compliant web browser. And yes, safe languages can be written in safe languages. See rust and servo.
This MISRA - https://en.wikipedia.org/wiki/MISRA_C ?