Ja, laten we allemaal in javascript gaan schrijven, want dat is zo handig voor ingewikkelde datastructuren... Zitten trouwens best veel geheugenfouten in windows, dus laten we ook maar alle bestuuringssystem in javascript gaan schrijven, wel zo veilig.

Niet zozeer JavaScript maar vooral Rust lijkt me een alternatief voor C en C++ software.

"Rust is a general purpose, multi-paradigm, compiled programming language developed by Mozilla Research.[3] It is designed to be a "safe, concurrent, practical language",[4][5] supporting pure-functional, concurrent-actor, imperative-procedural, and object-oriented styles."
https://en.wikipedia.org/wiki/Rust_%28programming_language%29

Een beetje een alternatief ook voor Google's Go

"Use after free" is echt niet het enige probleem waar je tegenaanloopt. Neem nou een taal als PHP. Prima automatisch geheugenbeheer, en toch een enorme bron van lekken. In een scripttaal, wie had dat nou gedacht?

Javascript zal wellicht een tijdje lijken te helpen, totdat er wat goochemerds uit de zandbak weten te breken. Dat zagen we met java en z'n java virtual machine ook. En toen bleek dat er nog maar twee of drie javascript-engines in breed gebruik waren, en toen kon je dus met een enkele exploit bij zeg een derde van de javascriptgebruikers naar binnen. In plaats van dat je voor ieder programma en iedere versie een aparte exploit moet verzinnen.

Persoonlijk heb ik geen problemen met C of C++, je moet je er alleen heel bewust van zijn dat ze je toegang geven op laag niveau. Als ik zo de mozilla code bekijk (en ik heb daar een tijdje professioneel in moeten grasduinen) dan willen ze dat zelf eigenlijk niet weten, laat staan dat ze zich indekken. Tsja, struisvogelprogrammeren helpt echt niet hoor.

Wat dat betreft ben ik dus niet zo vreselijk onder de indruk van deze mozillaman zijn wijsheid. Hoe zou dat nou komen?

Het voordeel van C/C++ is juist dat het op zoveel verschillende soorten processoren gecompileerd kan worden. Zeker als je jezelf beperkt tot de standaard-libraries. Want okay, Windows, Linux en OSX zijn wel de meest gebruikte systemen maar er zijn nog diverse computers (en embedded systemen) die een eigen besturings-systeem gebruiken waarbij C/C++ eigenlijk de enige ontwikkel-omgeving is.
Maar goed, programmeren in C/C++ is niet voor amateurs bedoeld. C/C++ gebruik je vooral voor geheugenbeheer en veel andere systemen leunen gewoon bovenop een systeem dat is geschreven in C/C++.

C/C++ is niet voor sloddervossen.

haha , ik waag te wedden dat java dus in C(++) is geschreven. "Voordeel" van C(++) is dat fouten vaak aan de programmeurs te wijten zijn terwijl bij java, dit waarschijnlijk de JRE of de SDK is die de lekken veroorzaakt .

Rare jongens die Mozillieëranen (vrij naar Obelisk) . En ja ik weet dat buiten de naam java script niets met java te maken heeft ;-) . Maar als je je applicaties niet in C(++) schrijft is er een gerede kans dat je het in een andere taal doet en dat is tegenwoordig denk ik vaak in java .

"Lekken" want lekker issie niet. En hoezo? Zit ik ernaast met de analyse dan?

Ah, Hugo, nu geef je jezelf te kennen. Je moet even dieper leren kijken. De "ontwerpers" van de "taal" PHP behoren namelijk óók tot die groep. En dat is goed te zien voor mensen die een beetje historisch besef ende ofte begrip van programmeertaalontwerp hebben.

Je "het is de schrijvert zijn schuld" kan ik net zo goed maken over C of C++. Neem alleen al de term "C/C++", wat in de praktijk betekent "halfliterate C met gebruikmaking van genoeg C++ features dat je aan een C-compiler niet genoeg hebt, maar zonder de voordelen van C++ werkelijk uit te benutten". Niet raar ook dat je die term dan ook vooral in de windows wereld terugvindt, waar de redmond "C++"-compiler lange tijd een "windows C(++)" heette te zijn--standaarden deden (en doen) ze maar heel mondjesmaat aan aldaar.

Mozilla code maakt het ook bont, door in hun code een stuk C++ opnieuw proberen uit te vinden. Niet heel gek want toen ze ermee begonnen waren er nog niet zoveel complete C++ implementaties beschikbaar. Maar opgeruimd hebben ze dat zooitje in de tussentijd ook niet.

En probeer maar eens behoorlijke documentatie te vinden over hoe hun code nu eigenlijk werkt zodat je snapt wat er gaande is. Het is heel makkelijk door de macros het grote plaatje en de valkuilen te missen.

Maar uiteindelijk is het prima veilige code in C en nog beter in C++ te schrijven... mits je weet wat je doet en je je programmeeromgeving goed opzet. Waarmee ik de structuur en de interne APIs van je programma bedoel. Dat de meeste schrijvers in deze talen daar niet toe in staat blijken, ach. Die situatie komt ons bekend voor, nietwaar?

Uiteindelijk hoef je trouwens maar door tdwtf te bladeren om te zien dat de meest vreemde en gevaarlijke constructies in ongeveer elke taal te vinden zijn, inclusief speciaal voor die minderbedeelde programmeurs ontworpen talen zoals c-hash en java en ja, ook php. Waarbij iig java door redelijk gerespecteerde ontwerpers inelkaar geklust is, met een hele filosofie en alles erbij. Zie eerder bericht over uit de zandbak ontsnappen.

Want ze is gecertificeerd veilig! Jawel.

Helaas... Java (JDK/JRE) is in Java geschreven. Dat wordt gecompiled door een compiler die geschreven is in een taal naar keuze (maar vaak C(++))

Natuurlijk kun je een (geheugen)lek in Java aanmerken als een JDK/JRE bug, maar omdat die kit zo generiek moet zijn, kun je het beter een feature noemen. Het is dan de verantwoordelijkheid van de programmeur om er goed mee om te gaan.
Zou die feature er niet zijn, dan is dat een beperking. Een Runtime Environment, maar zeker een compiler, moet doen wat er wordt opgedragen.

En naast C(++) en Java zijn er nog vrij veel alternatieven...

De zwakte van PHP is haar inconsistentie. Die inconsistentie wordt juist veroorzaakt doordat men het leven van niet-programmeurs wil vergemakkelijken. De vergelijkingsoperatoren zijn wel het mooiste voorbeeld:

Niet de taal is 'gevaarlijk' maar de programmeurs die er gebruik van maken. Als je weet dat een taal een probleem heeft, los dat probleem dan op. Dat kan je doen door een andere taal te gebruiken die geen last van het probleem heeft maar het is mijn inziens beter om met de berperkingen van het systeem te leren omgaan.

Het is echt niet zo ingewikkeld om de geheugen (en exit()) functies zelf uit te breiden met extra controles ter voorkoming van over-claiming en het niet vrijgeven van geheugen!

iedere 6 weken alle AV vendors op de kast jagen door hun plugins als incompatible aanmerken is wel veilig he Mozilla?

Hm, ik heb de OpenJDK-sources gedownload om een snelle indruk te krijgen en dit is die indruk (die klopt met wat ik al meende te weten):
- De standaard classlibrary's zijn grotendeels in Java geschreven, maar de koppeling naar het onderliggende OS in C en C++.
- De hotspot-compiler bevat ook veel Java, maar de OS- én de CPU-specifieke delen zijn in C++ geschreven.

De laatste is niet de compiler waarmee broncode naar bytecode wordt vertaald, maar de vertaling van bytecode naar native code voor CPU+OS, en dat is onderdeel van de Java-VM en daarmee onderdeel van Java (da's het hele platform, namelijk).

Dat Java in Java geschreven is is dus iets te kort door de bocht, het is *zo veel mogelijk* in Java geschreven, maar het bevat ook C/C++ voor de koppeling met OS en hardware.


En daarmee blijft de mogelijkheid dat Java C/C++-gerelateerde zwakheden bevat bestaan, al is het aandeel van die code een stuk kleiner dan SPlid veronderstelde.

"Mozilla: programmeren in C blijft gevaarlijk". Ik: dan kan je niet in C programmeren!

Dan ben jij vast een heel goede programmeur die zelfs met enorm complexe software code geen fout zou maken.

Sure, OpenBSD bedoel je? "Only two remote holes in the default install, in a heck of a long time!"

Veel commentaar van wannabe programmeurs hier die beweren dat je prima foutloos kan programmeren in deze talen. En dat de taal C geen extra nadelen zou hebben zoals het artikel beschrijft. Toch bewijst de praktijk het tegengestelde, en dat komt echt niet meer door onwetende programmeurs.

Uit de praktijk blijkt dat complexe code tot bugs leidt. Je kan niet met recht zeggen dat er geen rechtvaardiging is voor een discussie als deze.

Maar ga dan tenminste met open vizier de discussie in en zeg precies dat. Dat is niet wat deze figuur doet.