Frage:
Ist C nicht mehr eine gute Wahl für sicherheitsrelevante Software?
Aliquis
2016-03-10 23:01:00 UTC
view on stackexchange narkive permalink

C ist eine solide und weit verbreitete Programmiersprache, die besonders in der FOSS-Community sehr beliebt ist.

Viele sicherheitsrelevante Software (z. B. Verschlüsselungsbibliotheken) sind in C geschrieben und werden wahrscheinlich geschrieben in C auch in der Zukunft. Einer der Hauptgründe dafür ist die hervorragende Leistung und Portabilität von C-Programmen. Der Punkt ist jedoch, dass selbst sehr erfahrene Softwareentwickler Fehler wie Pufferüberläufe nicht verhindern können. Jedes Jahr finden sich ziemlich viele Sicherheitslücken im Zusammenhang mit der Speicherverwaltung in selbst sehr beliebter und überprüfter Software.

Meine Frage an Sie: Ist es heutzutage immer noch eine gute Idee, sicherheitsrelevante Software in C zu schreiben? Oder ist es nicht "Security by Design", moderne Sprachen wie Rust, Go oder höhere Sprachen wie Python zu wählen?

"Security by Design" wird durch die Wahl der Sprache nicht beeinflusst. Jede Sprache hat ihre eigenen Sicherheitsherausforderungen.
Es gibt Sicherheitsanwendungen, bei denen die Leistung so wenig zählt, dass man den Luxus hat, eine JIT-Sprache zu wählen. Für alles andere gibt es C.
Ich denke, [diese Frage] (http://security.stackexchange.com/q/115507/64787) wird von Interesse sein, wenn Sie sie noch nicht gesehen haben.
@schroeder Das klingt nach einer falschen Äquivalenz. Zeigen Sie mir alle Fehler in Java, bei denen ein Angreifer durch eine sorgfältig ausgearbeitete Benutzereingabe beliebigen Code in der JVM ausführen kann.
Obwohl ich den meisten Fragen zustimme, stimme ich der Prämisse des OP nicht zu, dass "C eine [...] solide Programmiersprache ist". Wie die Antwort von Tom Leek erklärt, ist es eine der spröderen Sprachen, in denen die wahre Semantik oft missverstanden wird (z. B. UB) und Portabilität ein Albtraum ist.
@Solomonoff'sSecret Ich setze nicht gleich.
@schroeder Was ist dann Ihr Punkt?
@Solomonoff'sSecret einfach, dass man "Sicherheit durch Design" nicht mit einer Sprachwahl ansprechen kann.
@schroeder Die Wahl der Sprache ist sicherlich nicht * ausreichend * (vielleicht, wenn die Sprache nicht speziell für diesen Zweck entwickelt wurde), aber sie kann helfen.
@Solomonoff'sSecret Ich weiß nicht, warum Sie dies als Knackpunkt wählen und daraus etwas machen, was es nicht ist. Sprache implementiert SbD, ist aber kein Faktor in SbD.
Python ist keine "sichere" Sprache wie ADA, d. H. Ohne Sorgfalt und Disziplin besteht meiner Meinung nach eine ziemlich nicht triviale Wahrscheinlichkeit, Fehler damit zu begehen. Andererseits ist es im Allgemeinen offensichtlich richtig, dass das Codieren in Sprachen wie Python, das mit Ganzzahlen beliebiger Größe in der bekannten Infix-Notation arbeiten kann, die Zeit des Programmierens und Debuggens erheblich verkürzen und folglich dem Entwickler einer Kryptosoftware ermöglichen könnte Weitere Anstrengungen unternehmen, um die Richtigkeit der der Software zugrunde liegenden Algorithmen sicherzustellen, was meiner bescheidenen Ansicht nach äußerst wichtig ist.
Sechs antworten:
#1
+49
Tom Leek
2016-03-10 23:22:14 UTC
view on stackexchange narkive permalink

Der Haupt- und fast einzigartige Grund, warum die meiste Software im Linux-Ökosystem in C geschrieben ist, ist Tradition . Entwickler sehen in C geschriebene Software, Bibliotheken mit einer C-basierten API, und verwenden daher C, weil dies praktisch ist. Compiler sind bereits vorhanden und funktionieren gut, da das gesamte Betriebssystem in C geschrieben ist.

Nichts davon besagt, dass C gut für die Entwicklung robuster Software ist. Tatsächlich ist C ziemlich schrecklich darin. Bei C muss der Entwickler jederzeit auf viele Dinge achten. C verfügt über viele Traps, die für kleinste Fehler bereit sind, darunter:

  • Ungeprüfte Array-Zugriffe, wodurch Überläufe möglich sind.
  • Manuelle Speicherverwaltung, die zu einer späteren Verwendung führt -freie oder doppelt freie Fehler und Speicherlecks.
  • Das gefürchtete "undefinierte Verhalten", das scheinbar vernünftige Ausdrücke amok laufen lässt (insbesondere signierte Operationen, die den darstellbaren Bereich überschreiten).
li> Portabilitätsprobleme beim Aufrufen von Architekturen mit unterschiedlichen Längen für Ganzzahltypen und Zeiger.

Was C wirklich gut kann, ist Folgendes:

  • Interaktion mit eine vorhandene Gruppe von Bibliotheken, die eine C-API anbieten. C ist die Verkehrssprache , die die Interoperabilität zwischen Softwarekomponenten auf vielen Plattformen ermöglicht.

Was C passabel gut kann, ist:

  • Schreiben von Code auf sehr niedriger Ebene (z. B. Kryptocode, der gegen Timing-Angriffe durch feste Speicherzugriffsmuster resistent ist), während versucht wird, ein gewisses Maß an Portabilität beizubehalten.

Meine Schlussfolgerung ist, dass C keine gute Idee ist, um sicherheitsrelevante Software im Allgemeinen zu schreiben, und dies schon seit einiger Zeit (mindestens ein Jahrzehnt) nicht mehr. C ist in bestimmten Kontexten immer noch gerechtfertigt, insbesondere wenn Sie auf eingebettete Plattformen abzielen (nicht eingebettet in "Smartphone", sondern eingebettet in "Smartcard"). Anstatt nach Gründen zu suchen, um sich von C zu entfernen, wäre es gerechtfertigter, nach bestimmten Gründen zu suchen, um C weiter zu verwenden.

Ich würde auch hinzufügen, dass C sein eigenes Ökosystem erzeugt. In C geschriebene Anwendungen verwenden in C geschriebene Bibliotheken. Mein Browser benötigt etwas, um beispielsweise SSL schwer zu heben. AFAIK Sie können nicht in etwas verlinken, das in einer anderen Sprache geschrieben ist, zumindest nicht einfach.
Welche Sprache würden Sie empfehlen?
@Adjit: hängt vom Kontext ab, aber als Ausgangspunkt ist C # nicht schlecht. Dank Mono kann in C # geschriebener Code unter Windows, OS X und Linux ausgeführt werden. Es verfügt über eine automatische Speicherverwaltung, überprüft Array-Zugriffe und kein undefiniertes Verhalten bei Ganzzahlberechnungen.
@Adjit: Wenn Sie eine Systemprogrammiersprache wünschen (z. B. wie C, in der Nähe des Metalls, mit manueller Speicherverwaltung), aber über umfassende Funktionen und Sicherheitsgarantien verfügt, ziehen Sie [Rust] in Betracht (https://rust-lang.org/). .
+1 "Anstatt nach Gründen zu suchen, sich von C zu entfernen, wäre es berechtigter, nach bestimmten Gründen zu suchen, um C weiter zu verwenden." - Ich würde argumentieren, dass dies für alle Sprachen für den spezifischen Zweck gilt, für den Sie es verwenden möchten, aber dies gilt insbesondere für eine Sprache mit so vielen möglichen Nachteilen wie C, trotz all der guten Dinge.
"Anstatt nach Gründen zu suchen, sich von C zu entfernen, wäre es berechtigter, nach bestimmten Gründen zu suchen, um C weiter zu verwenden." Wäre dies nicht besser als: "Anstatt nach Gründen zu suchen, sich von C zu entfernen, wäre es gerechtfertigter, nach bestimmten Orten zu suchen, an denen die Verwendung von C die richtige Wahl ist." Nachdem Sie es selbst gesagt haben, gibt es Teile eines Programms, die in C geschrieben werden sollten.
Unterstützung von C (ich bin total voreingenommen, Vorsicht): 1) ** C ist einfach **, keine ausgefallenen Vererbungstricks usw. zu beachten. 2) ** C ist flexibel **, genug, um ein (sicheres) Design durchzusetzen. 3) ** C ist weniger anfängerfreundlich ** und zwingt den Programmierer, sich der Konsequenzen und Architekturen bewusst zu sein. 4) ** Keine Sprache ist dafür ausgelegt (mehr) sicher **, z Der Standard-Zeichenfolgenvergleich ist keine konstante Zeit und sollte es auch nicht sein. Es ist leicht, Fehler in * C * zu machen? Ja. Ist es auch einfach, ein Design zu übernehmen, um sie zu verhindern? Ja. Diejenigen, die sich der Sicherheit nicht bewusst sind, werden immer * C # *, * Java *, * C * keinen Unterschied machen.
Auch die Geschwindigkeit sollte nicht vernachlässigt werden: Wenn Ihre Sockets etwas langsamer sind, ist der TCP-Handler etwas langsamer, der TLS-Handler etwas langsamer, der HTTP-Handler etwas langsamer, der HTML-Parser etwas langsamer und so weiter, die Software dann wird ziemlich langsam. Wenn andere Komponenten eine Bibliothek verwenden, muss diese schnell sein.
C ist eine großartige Sprache, aber nicht für fehleranfällige Menschen. Lassen Sie einen Compiler einer Hochsprache C für Sie schreiben (wählen Sie die Hochsprache natürlich sorgfältig aus.)
@MargaretBloom Ich bin anderer Meinung. Viele Fehler, die in C # und Java dazu führen, dass Ausnahmen ausgelöst werden, verursachen subtile Sicherheitslücken in C. Sie rufen einen Zeichenfolgenvergleich auf, der ein gutes Beispiel für den Sicherheitsmangel von C darstellt: Zahlreiche Zeichenfolgenfunktionen in der Standardbibliothek von C können zu unbeabsichtigtem und manchmal gefährlichem Verhalten führen für nicht nullterminierte Zeichenfolgen. Die Erfolgsbilanz von C in der Praxis ist beunruhigend, selbst wenn sie von erfahrenen Entwicklern geschrieben wurde, und es ist an der Zeit, die Schuld dahin zu bringen, wo sie hingehört.
Zu sagen, dass C mehr oder weniger von Natur aus sicher ist als eine andere Sprache (z. B. C #), ist wie zu sagen, dass eine Säge von Natur aus mehr oder weniger nützlich ist als ein Schraubendreher. Das stimmt einfach nicht. Ich kann C-Code schreiben, der * mindestens * so sicher ist wie C #, und ich kann C # -Code schreiben, der * weniger * sicher ist als C-Code. Die richtige Sicherheit beruht auf der Codeplanung, der ordnungsgemäßen Implementierung von Algorithmen und der Vertrautheit der Entwickler mit den vorhandenen Tools. Ich glaube nicht, dass ich jemals eine Sprache gesehen habe, die Entwickler zu 100% vor Fehlern schützen kann * und * immer noch nützlich / produktiv ist.
@phyrfox: Nein, es ist, als würde man sagen, eine Säge sei von Natur aus gefährlicher als ein Schraubenzieher ... was wahr ist.
@Solomonoff'sSecret In C gibt es keine "nicht nullterminierte Zeichenfolge" - das ist wie nicht nasses Wasser. Wenn es nicht nullterminiert ist, ist es keine Zeichenfolge.
@phyrfox Und ich kann eine Turing-Maschine erstellen, die mindestens so sicher ist wie alles in C oder C #. Zu diskutieren, was in jeder Sprache möglich ist, ist dumm und nicht, worum es bei dieser Frage geht.
Wenn der Compiler Grenzprüfungen und andere hilfreiche Dinge einfügt, kann er auch neue Seitenkanalangriffe eröffnen.
@immibis Richtig pedantisch, aber Sie wissen, was ich meine. Ordnen Sie Ihrem Zeichenpuffer einen zu kleinen zu oder vergessen Sie, am Ende eine \ 0 zu setzen, oder was auch immer Sie für einen unachtsamen Fehler machen und boomen könnten. Was Sie für eine Zeichenfolge halten, ist keine Zeichenfolge, und weder das Typsystem noch die Laufzeitprüfungen führen eine Zeichenfolge aus verdammte Sache, um dich zu retten.
#2
+25
T.E.D.
2016-03-11 01:39:50 UTC
view on stackexchange narkive permalink

Sie können sicheren Code in C schreiben. Es ist nur so, dass die Sprache standardmäßig unsicher ist . Die Sicherheit muss manuell mit zusätzlichem Code angegangen werden (der natürlich selbst Fehler enthalten kann).

Aus diesem Grund war C nie wirklich die beste Wahl für sicherheitskritische Software. Es wurde ohnehin in FOSS verwendet, da kostenlose Compiler dafür in der Vergangenheit auf nahezu jeder Plattform verfügbar waren (per Definition für jede Plattform, die gcc unterstützt).

Der allgemeine Rat für sicherheitskritische Software, wenn Sie nicht da sind. An eine bestimmte Sprache (wie C) gebunden ist die Verwendung von Ada. Diese Sprache befindet sich auf einer ähnlichen Abstraktionsebene wie C oder C ++, ist jedoch standardmäßig sicherheitsrelevant (z. B. automatische Überprüfung der Grenzen für alle Arrays) und bietet die Möglichkeit, Code hinzuzufügen, um Überprüfungen auszuschalten und nicht die andere andersherum.

Insbesondere gibt es eine Untergruppe von Ada namens SPARK, die speziell für sicherheitskritische Software entwickelt wurde. Es kann auch zur formalen Überprüfung von Software verwendet werden, wenn Sie sich für solche Dinge interessieren.

#3
+5
Has QUIT--Anony-Mousse
2016-03-11 04:26:13 UTC
view on stackexchange narkive permalink

Zuallererst ist für Dinge wie Verschlüsselung Leistung wichtig .

Es ist der Unterschied, ob Hunderte von Benutzern oder nur 10 gleichzeitig bedient werden können. Dies hat einige Sicherheitsrelevanz: Wenn Ihre Server Probleme haben, können sie leicht mit einem DOS-Angriff entfernt werden.

Wenn Sie jemals reinen Python-Code mit nativem Code verglichen haben, werden Sie überrascht sein wie groß die Unterschiede sind.

Zweitens gibt es kein Python / Java ohne C . Unabhängig davon, welche "moderne" Sprache Sie betrachten, werden eine beträchtliche Anzahl von Bibliotheken darunter verwendet. Und raten Sie mal, die meisten davon sind C-Bibliotheken.

Wenn Sie nun eine "sicherheitskritische" Bibliothek in einer solchen Sprache schreiben, müssen Sie sich um 1. Probleme in Ihrem eigenen Code 2. Probleme in der Java / Python-Code, den Sie verwenden 3. Probleme im zugrunde liegenden C-Code (es gibt häufige Sicherheitsupdates für Java!) Und 4. Probleme in den darunter liegenden C-Bibliotheken, die sich ändern , ohne dass Sie es wissen (z. B. Betriebssystem-Updates) ). Wenn Sie sicherheitsrelevanten Code wünschen, minimieren Sie Abhängigkeiten.

Die Menge an C darunter nimmt zu und nicht ab . Dies mag nicht offensichtlich erscheinen. Aber Numpy, Tensorflow, JavaFX, ... diese verwenden alle viel C-Code darunter, wegen der Leistung .

Viele Probleme könnten durch sorgfältiges Engineering und vermieden werden ausführliche Programmierung. Zum Beispiel wurde der OSX-Fehler "goto fail" dadurch verursacht, dass Programmierer nicht die bewährte Methode befolgten, immer Klammern zu verwenden ...

  wenn (a) goto fail; goto fail; etwas anderes  

ist in den meisten Sprachen (außer Python, wo Sie für dasselbe Problem zwei Leerzeichen weniger benötigen) ein leicht zu übersehender Fehler, der einfach mit Ausführlichkeit vermieden werden kann:

  if (a) {goto fail; goto fail;} etwas anderes  

Es ist nicht so, als ob Python sehr hilfreich wäre, um solche Probleme zu vermeiden (tatsächlich würden Java-Compiler Sie vor nicht erreichbarem Code warnen - Python nicht, und C-Compiler können dies, wenn sie vom Benutzer aktiviert werden) ... Am Ende Entwicklerdisziplin bleibt ein Schlüsselfaktor.

C-Code erfordert normalerweise viel mehr Sorgfalt beim Schreiben. Das ist nicht eine schlechte Sache für die Qualität. Der Hauptnachteil ist, dass es langsamer zu entwickeln ist.

Eigentlich hilft Python, solche Probleme zu vermeiden. Das spezifische Beispiel, das Sie für einen Fehler gegeben haben, der durch eine Diskrepanz zwischen Einrückung und Blockstruktur des Codes verursacht wurde, wäre in Python unmöglich. Dies liegt daran, dass in Python der Einzug die Grenzen von Codeblöcken bestimmt. Das Beispiel, das Sie gegeben haben, ist das Poster-Beispiel dafür, warum die Python-Methode zum Definieren von Blöcken nützlich ist. Es ist möglich, viele Beispiele für Probleme zu finden, die mit Python nicht gelöst werden könnten. Das Beispiel, das Sie gegeben haben, ist keines davon.
Dieser besondere Fall: ja. Im Allgemeinen: nein. ** Python toleriert nicht erreichbaren Code **. Schlimmer noch, es toleriert sogar undefinierte Variablen im Code, die noch nicht erreicht wurden. Wenn Sie also keine 100% ige Codeabdeckung mit Tests haben, können sogar solche Fehler auftreten, die verschiedene schwerwiegende Probleme verursachen können.
In jeder Turing-vollständigen Sprache können Sie Programme mit nicht erreichbarem Code schreiben. Das Erkennen von nicht erreichbarem Code entspricht dem Lösen des Stoppproblems. Einige Compiler erkennen einige Fälle von offensichtlich nicht erreichbarem Code und warnen davor. Der Compiler erkennt jedoch niemals alle Fälle von nicht erreichbarem Code. Manchmal haben Sie sogar Code, der nicht erreichbar sein soll - normalerweise zum Drucken einer Fehlermeldung über einen Fehler im Code.
Natürlich können Sie Python-Code schreiben, der zur Laufzeit garantiert einen "NameError" oder "TypeError" erzeugt. Statisch typisierte Sprachen fangen diese normalerweise beim Kompilieren ab. Ich habe sicherlich nicht impliziert, dass Python alle Probleme lösen würde. Ich habe nicht einmal eine Aussage darüber gemacht, ob Python eine bessere Wahl ist oder nicht. Ich habe nur darauf hingewiesen, dass Sie, wenn Sie ein Beispiel für ein Problem geben möchten, das nicht mit Python gelöst wurde, buchstäblich kein schlechteres Beispiel hätten wählen können.
Solche Fälle entstehen normalerweise nicht aus ** sicherheitsrelevanten Programmierfehlern **. Es ist genug (und sehr zu empfehlen), dass der Compiler solche grundlegenden Überprüfungen durchführt, auch wenn die Wissenschaft sagt, dass Sie sich trotzdem irgendwie in den Fuß schießen können. Und Sie könnten sogar Compiler-Hinweise haben, die "angeblich nicht erreichbar" sind.
Mein Punkt war nicht Python, sondern * Autorendisziplin *. Heartbleed war ein sehr realer Programmierfehler. Aufgrund der mangelnden Bereitschaft, die Sprach- (Block-) und Compilerfunktionen (nicht erreichbarer Code) gut zu nutzen. Diese Python hätte dies aufgrund der obligatorischen Einrückung verhindert, ist nur ein Zufall.
Durch die Disziplinierung des Codierungsstils werden Fehler in allen Sprachen reduziert. Wenn Sie 100% des Codes mit Unit-Tests abdecken, werden Fehler in allen Sprachen reduziert. Ja, Herzblut war ein echter Fehler mit Auswirkungen auf die Sicherheit. Es war jedoch ein Pufferüberlauf, was in Python normalerweise nicht vorkommt - außer wenn sich der Fehler in einer der zugrunde liegenden C-Bibliotheken befindet. Und obwohl "NameError" und "TypeError" zur Laufzeit lästige Fehler sind, handelt es sich selten um Sicherheitsprobleme.
Tatsächlich war dieses Beispiel "goto fail", nicht "heartbleed", und es ist * kein * Pufferüberlauf, sondern ein Fehler bei der Eingabevalidierung. In Python gibt es keinen automatischen Schutz gegen Fehler bei der Eingabevalidierung. Fügen Sie einfach frühzeitig "return true" in Ihre Validierungsmethode ein. Die einzige Hilfe, die eine Sprache hier bieten kann, besteht darin, nicht erreichbaren Code zu erkennen und vor nicht initialisierten Variablen zu warnen (ein Teil von goto fail bestand darin, den Erfolg "standardmäßig" zurückzugeben).
Es ist immer noch kein gutes Beispiel. Dies hätte durch bessere Programmierpraktiken vermieden werden können. Aber Python erzwingt tatsächlich bessere Praktiken in diesem Bereich durch das Design der Sprache.
Wenn Sie diesen Beitrag lesen, haben Sie möglicherweise den Eindruck, dass Java und seine Bibliotheken in C geschrieben sind. Dies ist völlig falsch. Die meisten Java-Compiler (in der Tat die meisten Compiler mit Selbstachtung für * jede * Sprache) sind selbst gehostet (die Quellen sind in ihrer eigenen Sprache geschrieben).
** Fakt ist **, das sind: [Java Hotspot ist C ++ mit vielen Assembler-Inline] (http://hg.openjdk.java.net/jdk8/jdk8/hotspot/file/87ee5ee27509/src/cpu/x86/ vm) ist der übliche Python-Interpreter [CPython] (https://github.com/python/cpython/tree/master/Python) in C (nicht in Jython in Java). Überprüfen Sie die Quellen der JVM / des Interpreters.
Diese Antwort scheint auf einer falschen Zweiteilung von "C vs. Python" (oder "C vs. Java") zu beruhen. Das ist nicht wahr. Es gibt eine Reihe von Sprachen mit "C-ähnlicher" Leistung, die viele oder alle Probleme von C vermeiden. Das "goto fail" war auch kein Versagen der Sprache oder "schlechte Codierungspraktiken". Es war ein Fehler bei Codeüberprüfungen und automatisierten Tests.
#4
+2
Arif Burhan
2016-03-11 06:28:03 UTC
view on stackexchange narkive permalink

C wird seit über 20 Jahren von Millionen von Menschen verwendet. Die Sicherheitslücken, wie die mit scanf () , sind bekannt und dokumentiert, und es gibt etablierte und stark getestete Problemumgehungen.

Eine neuere Sprache, z. B. Perl 6 oder Python 3 wurde nur für kurze Zeit verwendet, nur wenige Personen sind Experten in diesen Bereichen, es können Sicherheitslücken bestehen, die noch nicht gefunden wurden, und kritische Überprüfungen und Dokumentationen sind spärlich.

Diese beiden neueren Sprachen sind es viel 'größer' als C mit weitaus mehr Fähigkeiten, und es kann sehr viel mehr als 20 Jahre dauern, bis alle möglichen Programmierkonstrukte verwendet wurden, und wir können uns ihrer Sicherheit sicher sein.

#5
  0
ljrk
2016-03-11 04:36:16 UTC
view on stackexchange narkive permalink

Es ist niedrig und standardmäßig völlig unsicher. Natürlich ist es möglich, sichere Software zu schreiben - aber Sie müssen gut darin sein. OTOH: C ist auf niedriger Ebene und Sie müssen keine Bibliotheken einschließen, die möglicherweise eigene Sicherheitsprobleme haben - dies könnte sei gut. Auch sollte man nicht vergessen, dass eine "sichere" Sprache bedeutet, dass es sich um Programme handelt, die wiederum ein mögliches Sicherheitsproblem darstellen.

Persönlich Ich würde wahrscheinlich die Verwendung von Rust empfehlen, da es ausreichend niedrig sein kann und sich auch auf die Sicherheit konzentriert.

Ich würde keinen nicht nativen Code verwenden ( dh nicht Java, C # usw.), es sei denn, Sie liefern Ihre eigene Laufzeit. Das Gleiche gilt natürlich für jede Bibliothek, auf die Sie verlinken, aber dies kann im Gegensatz zu nicht nativem Code vermieden werden.

Alles in allem sollten Sie sich auf den geringstmöglichen Code konzentrieren, d. H. Machen Sie es so einfach wie möglich und vertrauen Sie keinem anderen Code. Wenn Sie dies jedoch vermeiden können, vertrauen Sie nicht darauf, dass Sie sicheren Code schreiben - dies ist normalerweise nicht gut.

Wenn man bedenkt, dass Betriebssysteme in C geschrieben sind, können Sie so gut wie kein Programm verwenden, da Links zum Betriebssystem als schlecht angesehen werden.
@AstroDan Ja, natürlich ist das Betriebssystem problematisch. Aber es kommt darauf an, wie weit Sie gehen möchten - und ich gehe davon aus, dass OP nicht vorhatte, sein eigenes Betriebssystem zu schreiben. Sie sollten viel minimieren, aber irgendwann müssen Sie einfach aufhören. Aber wenn Sie es vermeiden können (dh 1000 Bibliotheken nicht zu verwenden, ist einfacher als ein Betriebssystem als Voraussetzung zu vermeiden): Machen Sie es.
#6
-1
Alexey Vesnin
2016-03-11 02:45:29 UTC
view on stackexchange narkive permalink

Der Grund für die Persistenz von C ist keine Tradition, sondern eine Portabilität und eine sehr zulässige API + lib. Ja, es denkt für Sie nicht wie ein hochrangiger Müll, die Sprache wurde in der festen Überzeugung erstellt, dass es nur ein Werkzeug zur Umsetzung Ihrer Idee ist. Wenn die Idee selbst schlecht / mit Fehlern gestaltet ist, nicht nur Sicherheitslücken - keine Sprache wird sie vollständig retten. Ja, einige neue "Produkte", die auf dummen Programmierern basieren, werden versuchen , das Problem am besten zu verhindern, aber sie werden nicht erfolgreich sein, nicht bei allen Problemen. Verwenden Sie Gehirn, Standard, Debugger und valgrind - und Sie werden C lieben für das, was es ist.

C-Quellen sind tatsächlich weniger portabel als fast jede Sprache, die ich kenne. Multiplattform-C-Programme enthalten in der Regel Abschnitte (manchmal die Mehrheit) von nahezu unlesbaren Websites mit bedingt kompiliertem Code. Es ist der C-Compiler * selbst *, dessen Portierung nicht viel Arbeit kostet, da die Sprache relativ einfach ist und so ziemlich jede Plattform eine hat.
+1 Die Vertrautheit des Entwicklers mit Logik, Programmierung und einer bestimmten Sprache / einem bestimmten Tool bestimmt die Sicherheit des Endprodukts (bis Sie zumindest über die Sicherheit eines bestimmten Hardwaremoduls sprechen). C für etwas zu beschuldigen, das nicht seine Schuld ist, ist einfach schlecht. Ich habe in meinem Leben Code in wahrscheinlich 20 bis 30 Sprachen geschrieben und festgestellt, dass jede Sprache ungefähr so ​​sicher ist, wie Sie es machen. Da ich Erfahrung in der Programmierung gesammelt habe, habe ich die Anzahl der Fehler, die ich pro LOC schreibe, reduziert. Erfahrung macht den Programmierer aus.
@T.E.D. Bedingt kompilierte Codes ** sind ** eines der mächtigsten Dinge in C. Erstellen Sie Unterprogramme / Definitionen für plattformspezifische Aktionen, trennen Sie sie durch Platzieren in ordnungsgemäß benannten Unterordnern + Dateien und stellen Sie sicher, dass sie "ausgelöst" werden. reflektieren Sie es nur bei Bedarf in Ihrem Makefile. Es ist ** so ** einfach. Schlecht organisierte Codes sind nervig, da stimme ich voll und ganz zu, aber dies ist kein sprachspezifisches Problem: Es ist ein ** Fehler ** im Kopf des "Entwicklers", nicht in einer Sprache, die ein geeignetes Instrument zulässt.
@phyrfox mich auch: über 20 Sprachen, verschiedene Plattformen - und ** keine Übereinstimmung ** für C / ObjC-Portabilitätsleistung. Und ja - ** nur ** ein Geist + Erfahrung macht einen Menschen zu einem Programmierer. Ich bin ein autodidaktischer Mann, und als ich einige IT-Absolventen sah, wurde ich zum Albtraum: Menschen können in Bildungseinrichtungen nichts kaufen, was ihnen nicht von Gott gegeben wurde, IMHO
@AlexeyVesnin Re "High-Level-Müll": Ich verstehe diesen Teil überhaupt nicht. Antworten Sie unter dem Gesichtspunkt der Hobbyentwicklung im Gegensatz zur beruflichen Entwicklung?
@BalinKingOfMoria Mit diesem Begriff meine ich die Dinge, die versuchen, die Arbeit des Programmierers zu erledigen. Hobby, Beruf, Berufsbezeichnung usw. ** Entwicklung ** ist ein Prozess, bei dem der Programmierer einen Algorithmus, eine Reihe von Tests und Dokumenten erstellt und ihn mit einem ** Tool ** implementiert Lösen der Spitze eines Eisbergs, ohne alle Situationen "Was ist, wenn etwas nicht stimmt" im selben Code zu behandeln. Wir haben alle als Hobbysts angefangen, aber das berufliche Wachstum bedeutet für mich einen Evolutionsprozess, nicht nur auswendig zu lernen und auf dem gleichen Niveau zu bleiben.
@AlexeyVesnin Ich frage mich nur, woher Sie in Bezug auf dieses spezielle Problem kommen, da kein professioneller Programmierer absichtlich die "Herausforderung" annehmen sollte, "hochrangigen Müll" wegzuwerfen, da dies ein schlechter Dienst für sein Unternehmen wäre.
@BalinKingOfMoria Ich spreche nicht von heiligen Kriegen, ich bin dafür, ein * richtiges * Werkzeug für eine Aufgabe zu verwenden.
@AlexeyVesnin Ich beziehe mich speziell auf die Aussage "High-Level-Müll". Das Wiederholen der Arbeit aufgrund der Idee, dass X das ultimative Werkzeug ist, ist niemals eine gute Idee.


Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 3.0-Lizenz, unter der er vertrieben wird.
Loading...