On 04/09/2014 10:35 AM, J.Witvliet@mindef.nl wrote:
-----Original Message-----
From: users-bounces@lists.fedoraproject.org [mailto:users-bounces@lists.fedoraproject.org] On Behalf Of g
Sent: woensdag 9 april 2014 9:19
To: users@lists.fedoraproject.org
Subject: Re: Coding Practice [was Re: Serious OpenSSL vulnerability]



On 04/09/14 11:35, Jonathan Ryshpan wrote:
<<>>

It's an interesting question why Net infrastructure code
 > continues to be written in C, a language that provides no 
 > automatic checks for buffer overflow, which (if I understand   right) is the opening for this security breach, along with so  
many others.  And why is the code run on hardware that provides  
no such checks?  There have been languages and system that check  
for overflow available for 40 years.
from early times, c, c++ and the various "enhancements", were used because it was a universal language that code/source, could be written under 1 cpu and transferred to another and still run because code/source was run thru a cpu specific compiler.

something that could be done with basic, fortran, python, and other 'high  level' languages. but, with the most efficient language, assembler, such could not be.
c and c++ are not interchangeable in there code. nor is c++ an enhancement or super set of c. they are each in their own world.
because of all the routines that where built up for c/c++, it soon became a sudo standard in programming. yet it falls short in ability of specific uses and will never replace fortran, python and other high levels.
c/c++ is a very inefficient language, yet it has been accepted as 'the language to learn and use'. a very bad misconception.
compactors have been written for c/c++, but even after many hours to days, and longer of running compactors, c/c++ still fail to be reduced to what can be done with high level languages, and will never come any where near the compactness of assembler.
the worst fault of c/c++ is buffer overflow, yet know one seems to really care. mainly an attitude of 'if it overflows, we will worry about it then'. not the best way to think.
if one were to run an analysis of programs that are hacked and of security that has been broken, one would find that what is written with c/c++ is the easiest to hack and break. a nature of the beast.
Why doesn't anyone use them?
because they are easy to understand, learn and use.
-----Original Message-----

Sorry, but I have to disagree.
I date back from the ages where one _had_ to learn & write in assembly, mainly because other languages were way to slow.
And I was pleasantly surprised that drivers for network-cards and disks could be written in "C" without timing errors.

The quality of the code is not related to the language being used. Only to the person doing the coding.
Relying on others to do checking only breeds lazy programmers and bloated code.
And whatever language you use, people  can still create unreadable spaghetti-code ;-)

I'd like to comment a bit. I am primarily a C/C++ programmer, but in the past I was a COBOL programmer as well as FORTRAN, BASIC and several assembly languages. I also have been in a compiler team in that I ported Lint(1) to Tru64 Linux.
I agree with the above 2 paragraphs, but also I have some experience on C code optimizers. C Code optimizers are difficult. One reason is that C and C++ allow pointers. Using pointers, for instance to go through an array, will essentially not allow the code to be optimized. The same code using subscripts can be optimized. Good C compilers have a number of optimizing steps. On the Alpha, we had a post code generation optimizing step that would reorder the code to allow for simultaneous operations. But, if you compare FORTRAN to C, FORTRAN can be highly optimized because it does not contain some of the more powerful features that C has. So, for a pur math or physics problem I would definitely want the program written in FORTRAN.. But, C was designed for writing operating systems. And while C++ has evolved into a separate language, it retains some of the elements of C.



--
Jerry Feldman <gaf@blu.org>
Boston Linux and Unix PGP key id:3BC1EB90
PGP Key fingerprint: 49E2 C52A FC5A A31F 8D66 C0AF 7CEA 30FC 3BC1 EB90