7 ms·

Hi, thank you for the pointers! I try not to include C or C++ projects other than for educational purpose (like the Mandelbrot set) because one of my life's go

Hi, thank you for the pointers! I try not to include C or C++ projects other than for educational purpose (like the Mandelbrot set) because one of my life's goal is to help the world to transition to a C & C++ free world (other than for kernels...). I believe that my role is to promote projects which are "building the new world" and thus we need to abandon and port all form insecure core.

sk0g 7y ago
So in an article about high/extreme performance systems, you're ignoring the vast majority of them because you don't agree with the tool used to achieve said performance? What..?
- pjmlp 7y ago
  I guess because using other programming languages proves the point that there are other approaches, instead of reinforcing the status quo.
  - z0mbie42 7y ago
    Exactly this
- z0mbie42 7y ago
  I believe that performance is irrelevant without correctness and security. My opinion is that C and C++ can't bring enough security and correctness guarantees for mere mortals (lack of tooling, language features...). Yes some correct and secure programs are written in C and C++ but it's not and will never be the norm.
fermentation 7y ago
Despise of C and an interest in high-performance, a unique mix.
- pjmlp 7y ago
  Back in the 80's C was anything but high performance. Only with people willing to challenge the status quo do we move forward.
  - beagle3 7y ago
    It was always higher performance than e.g. Pascal or Basic on any relevant platform (the cost was lack of error checking, e.g. array bounds). And it was slower than FORTRAN on most 32-but platforms such as DEC, Sun and IBM Unix workstations, VAXen and mainframes - but it was still the speed king on the most prevalent platform of the time, 8086/80286 and friends.
    - pjmlp 7y ago
      Only as urban myth scattered around by the C crowd. As user from all Borland product until they changed to Inprise, it was definitely not the case. Pascal and Basic compilers provided enough customization points. When one of them wasn't fast enough versus Assembly, none of them were. I used to have fun showing C dudes in demoscene parties how to optimize code. Now, if you are speaking about the dying days of MS-DOS, when everyone was jumping into 32 bit extenders with Watcom C++, then we are already in another chapter of 16 bit compiler history.
      - BubRoss 7y ago
        This doesn't line up with the reality that almost all games were written in combinations of C and asm.
        pjmlp 7y ago
        During 8 bit days, all games that mattered were written in Assembly. During the 16 bit days, Pascal, Basic, C, Modula-2, AMOS were the "Unity" of early 90's game developers, with serious games still being written in Assembly. The switch to C occurred much later at the end of MS-DOS lifetime, when 386 and 486 were widespread enough, thanks success like Doom and Abrash books. Easy to check from pouet, hugi, breakout, Assembly or GDC postmortem archives.
hedora 7y ago
Some of the most secure software is written in C. The language matters less than you’d think once you get past a certain correctness baseline.
- z0mbie42 7y ago
  I have not doubts that secure software can be written is C, but it's not the norm and it's too easy to introduce vulnerabilities in C for mere mortals.
adev_ 7y ago
By the sake of god, please stop to put C and C++ in the same basket when talking about security. It just show you do not know what you are talking about. Most security problems affecting C program DO NOT affect C++ programs. Stack smash, vla abuse, string null termination problems, goto error control, double free corruption do NOT affect C++, they are C specific.
- z0mbie42 7y ago
  C++ is too large and huge to not shoot yourself in the foot (or of your user's) in one way or another.
  - adev_ 7y ago
    This argument has been debunked 20 times already.
    - pjmlp 7y ago
      And 20 times more in security reports from Microsoft, Google and Apple.
- pjmlp 7y ago
  Unfortunately they surely do, because a large set of developers writes C++ code full of C idioms. Which is why Google has thrown out the towel and Android 11 will require hardware memory tagging for native code, and now everything is compiled with FORTIFY enabled. Also Microsoft research shows otherwise, https://msrc-blog.microsoft.com/2019/07/16/a-proactive-approach-to-more-secure-code/ https://msrc-blog.microsoft.com/2019/07/16/a-proactive-appro... > ~70% of the vulnerabilities Microsoft assigns a CVE each year continue to be memory safety issues So yeah, you are correct that C++ does offer the tools not to write C like security holes. Now you just need to convince a large spectrum of companies to actually stop doing C idioms while writing C++ code.
  - adev_ 7y ago
    > Unfortunately they surely do, because a large set of developers writes C++ code full of C idioms. That's an other problem, not technical but educational. A lot of (older) programmer came to C++ passing by C and continue to use C in C++. That need time, education and guidelines to change that... a lot of time. Changing mindset and programmer education is sometimes harder than changing the program itself. > Now you just need to convince a large spectrum of companies to actually stop doing C idioms while writing C++ code. That is already ongoing. However do not forget that C++ has a bagage of 25 years of code pre-C++11 to upgrade before arriving there.
bityard 7y ago
I mean, have you even _seen_ the trail of CVEs that Java has left in its wake over the past few decades?
z3phyr 7y ago
In my opinion, we should instead focus on hardware and experiment more with different kinds of cpus, memory, co-processors etc. The key to newer software systems are newer kinds of hardware, for which you can write newer experimental systems in the language of your own designs. The sky is the limit, and there is so much to do! Transactional memory, massively multicore computers, hardware built on predicate logic, neuromorphic computers, and whatnot. We are still mostly stuck with the cpu and memory designs of old.

sk0g 7y ago

So in an article about high/extreme performance systems, you're ignoring the vast majority of them because you don't agree with the tool used to achieve said performance? What..?

pjmlp 7y ago
I guess because using other programming languages proves the point that there are other approaches, instead of reinforcing the status quo.
- z0mbie42 7y ago
  Exactly this
z0mbie42 7y ago
I believe that performance is irrelevant without correctness and security. My opinion is that C and C++ can't bring enough security and correctness guarantees for mere mortals (lack of tooling, language features...). Yes some correct and secure programs are written in C and C++ but it's not and will never be the norm.

fermentation 7y ago

Despise of C and an interest in high-performance, a unique mix.

pjmlp 7y ago
Back in the 80's C was anything but high performance. Only with people willing to challenge the status quo do we move forward.
- beagle3 7y ago
  It was always higher performance than e.g. Pascal or Basic on any relevant platform (the cost was lack of error checking, e.g. array bounds). And it was slower than FORTRAN on most 32-but platforms such as DEC, Sun and IBM Unix workstations, VAXen and mainframes - but it was still the speed king on the most prevalent platform of the time, 8086/80286 and friends.
  - pjmlp 7y ago
    Only as urban myth scattered around by the C crowd. As user from all Borland product until they changed to Inprise, it was definitely not the case. Pascal and Basic compilers provided enough customization points. When one of them wasn't fast enough versus Assembly, none of them were. I used to have fun showing C dudes in demoscene parties how to optimize code. Now, if you are speaking about the dying days of MS-DOS, when everyone was jumping into 32 bit extenders with Watcom C++, then we are already in another chapter of 16 bit compiler history.
    - BubRoss 7y ago
      This doesn't line up with the reality that almost all games were written in combinations of C and asm.
      - pjmlp 7y ago
        During 8 bit days, all games that mattered were written in Assembly. During the 16 bit days, Pascal, Basic, C, Modula-2, AMOS were the "Unity" of early 90's game developers, with serious games still being written in Assembly. The switch to C occurred much later at the end of MS-DOS lifetime, when 386 and 486 were widespread enough, thanks success like Doom and Abrash books. Easy to check from pouet, hugi, breakout, Assembly or GDC postmortem archives.

hedora 7y ago

Some of the most secure software is written in C. The language matters less than you’d think once you get past a certain correctness baseline.

z0mbie42 7y ago
I have not doubts that secure software can be written is C, but it's not the norm and it's too easy to introduce vulnerabilities in C for mere mortals.

adev_ 7y ago

By the sake of god, please stop to put C and C++ in the same basket when talking about security. It just show you do not know what you are talking about. Most security problems affecting C program DO NOT affect C++ programs. Stack smash, vla abuse, string null termination problems, goto error control, double free corruption do NOT affect C++, they are C specific.

z0mbie42 7y ago
C++ is too large and huge to not shoot yourself in the foot (or of your user's) in one way or another.
- adev_ 7y ago
  This argument has been debunked 20 times already.
  - pjmlp 7y ago
    And 20 times more in security reports from Microsoft, Google and Apple.
pjmlp 7y ago
Unfortunately they surely do, because a large set of developers writes C++ code full of C idioms. Which is why Google has thrown out the towel and Android 11 will require hardware memory tagging for native code, and now everything is compiled with FORTIFY enabled. Also Microsoft research shows otherwise, https://msrc-blog.microsoft.com/2019/07/16/a-proactive-approach-to-more-secure-code/ https://msrc-blog.microsoft.com/2019/07/16/a-proactive-appro... > ~70% of the vulnerabilities Microsoft assigns a CVE each year continue to be memory safety issues So yeah, you are correct that C++ does offer the tools not to write C like security holes. Now you just need to convince a large spectrum of companies to actually stop doing C idioms while writing C++ code.
- adev_ 7y ago
  > Unfortunately they surely do, because a large set of developers writes C++ code full of C idioms. That's an other problem, not technical but educational. A lot of (older) programmer came to C++ passing by C and continue to use C in C++. That need time, education and guidelines to change that... a lot of time. Changing mindset and programmer education is sometimes harder than changing the program itself. > Now you just need to convince a large spectrum of companies to actually stop doing C idioms while writing C++ code. That is already ongoing. However do not forget that C++ has a bagage of 25 years of code pre-C++11 to upgrade before arriving there.

bityard 7y ago

I mean, have you even _seen_ the trail of CVEs that Java has left in its wake over the past few decades?

z3phyr 7y ago

In my opinion, we should instead focus on hardware and experiment more with different kinds of cpus, memory, co-processors etc. The key to newer software systems are newer kinds of hardware, for which you can write newer experimental systems in the language of your own designs. The sky is the limit, and there is so much to do! Transactional memory, massively multicore computers, hardware built on predicate logic, neuromorphic computers, and whatnot. We are still mostly stuck with the cpu and memory designs of old.