-----Original Message-----
From: users-boun...@lists.fedoraproject.org 
[mailto:users-boun...@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 ;-)



______________________________________________________________________
Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet 
de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u 
verzocht dat aan de afzender te melden en het bericht te verwijderen. De Staat 
aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband 
houdt met risico's verbonden aan het electronisch verzenden van berichten.

This message may contain information that is not intended for you. If you are 
not the addressee or if this message was sent to you by mistake, you are 
requested to inform the sender and delete the message. The State accepts no 
liability for damage of any kind resulting from the risks inherent in the 
electronic transmission of messages.
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Reply via email to