1. Foren
  2. Kommentare
  3. Security
  4. Alle Kommentare zum Artikel
  5. › Linuxtag-Keynote: Lehren aus…
  6. Them…

Programmiersprachen C und C++ == Grundsätzliches Problem

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


  1. Re: Programmiersprachen C und C++ == Grundsätzliches Problem

    Autor: Moe479 11.05.14 - 03:53

    ich denke es liegt weniger an der programmiersprache als am produzirtem code, ist der mangelhaft kann die beste programmiersprache der welt dafür nichts.

    nur weil c oder c++ oder oder oder es einem erlauben sich in den fuss zu schiessen muss man das ja nicht zwangsweise tun, oder?



    1 mal bearbeitet, zuletzt am 11.05.14 03:54 durch Moe479.

  2. Re: Programmiersprachen C und C++ == Grundsätzliches Problem

    Autor: nicoledos 11.05.14 - 08:41

    c und c++ bieten dir aber tausend möglichkeiten in den Fuß zu schießen. Dort halbwegs sicher zu programmieren erfordert sehr viel Erfahrung.

  3. Re: Programmiersprachen C und C++ == Grundsätzliches Problem

    Autor: nicoledos 11.05.14 - 08:53

    C mag überall verfügbar sein ist aber überall etwas anders. Einerseits bedingt durch die Hardware andererseits durch die Betriebssysteme. Jedes System (ARM, x86, 32Bit , 64Bit, Win, Linux, BSD, ... ). Um den Ärger zu umgehen gibt es dann die Bibliotheken inkl. eigener Datentypen. Aber dann kann man auch zu etwas greifen, was dies bereits mit bringt.

  4. Re: Programmiersprachen C und C++ == Grundsätzliches Problem

    Autor: bstea 11.05.14 - 09:25

    Woher hast du nur dein Wissen? Dieses Pascal wovon da die Rede ist, ist mit ziemlicher Gewissheit Concurrent Pascal.
    Standard Pascal unterstützt sehr wohl nullterminierte Zeichenketten wie pchar. Wäre auch blödsinnig weil bis TP7 Strings auf 255 Zeichen limitiert waren, was der Artikel auch falsch wiedergibt.
    Der Artikel ist auch so ziemlich mies, natürlich gibts verkürzte Schreibweise wie in C üblich:
    in C-> ++i; i+=2;
    in Pascal inc(i), inc(i, 2)

    --
    Erst wenn der letzte Baum gefällt, der letzte Fluss gestaut und der letzte Fisch gefangen ist, werdet ihr feststellen, dass man Biber nicht essen kann!

  5. Re: Programmiersprachen C und C++ == Grundsätzliches Problem

    Autor: bstea 11.05.14 - 11:06

    Zudem ist man als C/C++ Programmierer auf das Können anderen angewiesen. Die Standardbibliothek enthält nur das notwendigste.

    --
    Erst wenn der letzte Baum gefällt, der letzte Fluss gestaut und der letzte Fisch gefangen ist, werdet ihr feststellen, dass man Biber nicht essen kann!

  6. Re: Programmiersprachen C und C++ == Grundsätzliches Problem

    Autor: Poison Nuke 11.05.14 - 11:15

    Ob denn besserer Code rauskommt, wenn sich ein Programmierer auf das Framework verlässt?
    Nehmen wir mal eine Sprache wie Java, da bekommt man ja eine Exception nach der anderen geworfen, wenn man ungültige Indizes addressiert, aber ist das Programm danach wirklich sicherer, wenn man sich auf solche Funktionalitäten verlässt und dann einfach "lazy code" schreibt?
    Wenn dann an einer kritischen Stelle eine Exception fängt, die aber durch etwas völlig anderes verursacht wurde, und dann dafür die falschen Schritte ausführt, kann man auch in sehr undefinierte Zustände des Programms kommen. Dann hat man zwar kein Overflow im eigentlichen Sinne, aber eine falsche Position in einer Map oder so kann auch fatale Folgen haben.

    Seh da jetzt keinen Vorteil gegenüber einer Sprache, bei der man sich über alle Zustände von Pointern usw im Klaren sein muss, dafür aber nicht mit try/catch rumhantieren muss, was IMHO einem sauberen Code absolut entgegenwirkt.

    Greetz

    Poison Nuke

  7. Re: Programmiersprachen C und C++ == Grundsätzliches Problem

    Autor: bstea 11.05.14 - 14:39

    Zu der ersten rhetorischen Frage, ich würde die mit ja beantworten. Programmcode der nicht ausgeführt wird ist super sicher. Ich muss schon aktiv und explizit dumm handeln um da einen Fehler einzubauen. Man kann ja nur zwei was machen, entweder behandeln oder nach oben delegieren. Möchtest du lieber das der Code ohne Meldung so weiterläuft? Dein Beispiel würde so in allen Sprachen zu Problemen führen, wenn ich die Fehler nicht unter genug erkenne und den Blödsinn weitergebe und diesen Fall dabei nicht beachtet hab beim Entwurf .
    Das schöne an Java ist, es gibt keine Pointer. Sogesehen ist es schon mal ein Fortschritt ggü. C/C++, wo das Betriebssystem den Job übernehmen muss, damit das nicht zu einfach ausgenutzt werden kann.

    --
    Erst wenn der letzte Baum gefällt, der letzte Fluss gestaut und der letzte Fisch gefangen ist, werdet ihr feststellen, dass man Biber nicht essen kann!

  8. Re: Programmiersprachen C und C++ == Grundsätzliches Problem

    Autor: BRDiger 11.05.14 - 15:11

    bstea schrieb:
    --------------------------------------------------------------------------------
    > Das schöne an Java ist, es gibt keine Pointer. Sogesehen ist es schon mal
    > ein Fortschritt ggü. C/C++, wo das Betriebssystem den Job übernehmen muss,
    > damit das nicht zu einfach ausgenutzt werden kann.

    Naja das kann man auch anders sehen....ja ich weiß: Pointer und der Teufel sind eins.

    >Zudem ist man als C/C++ Programmierer auf das Können anderen angewiesen. Die >Standardbibliothek enthält nur das notwendigste.

    Naja auch das muss nicht schlecht sein. Für mich muss eine Sprache nicht zigtausend Dinge eingebaut haben wie fertige Datenstrukturen etc....

    Also ich habe immer noch kein großes Argument für Ada oder Pascal hier gehört und diffuse Vorteile wie "Höhere Prozesssicherheit" sollte man auch mal begründen...

    @nicoledos:
    C ist nicht überall etwas anders! Bitte Beispiele und Begründungen nennen. Ich weiß das ist schwerer als einfach etwas zu behaupten aber mir fällt es dann auch schwer das zu glauben.

  9. Re: Programmiersprachen C und C++ == Grundsätzliches Problem

    Autor: nolonar 11.05.14 - 17:31

    bstea schrieb:
    --------------------------------------------------------------------------------
    > Das schöne an Java ist, es gibt keine Pointer. Sogesehen ist es schon mal
    > ein Fortschritt ggü. C/C++, wo das Betriebssystem den Job übernehmen muss,
    > damit das nicht zu einfach ausgenutzt werden kann.

    Eigentlich gibt es in Java sehr wohl Pointer, nur werden diese wie gewöhnliche Variablen gehandhabt. Solche Variablen werden als "reference types" bezeichnet und unterscheiden sich von den "value types" stark.
    Pointer sind gerade deshalb wichtig, da man grössere Datenstrukturen so nicht auf dem Heap kopieren muss, um diese als Argumente an Funktionen übergeben zu können.
    Stell dir vor du hättest eine 3 MB grosse Bilddatei im Speicher, den du per Heap an die nächste Funktion übergeben musst. Was wäre schneller, eine 32/64 bit Addresse hinüberzukopieren, oder die gesammte 3 MB (ca. 3 Millionen bits)?
    "Value types" sind typischerweise Integer, Floats, Doubles oder Bools; dafür braucht man nur in den seltensten Fällen einen Pointer, da der eigentliche Wert der Variablen bereits 32/64 bit klein ist.


    Kurz: Es gibt Pointer in Java, und fehlende Unterstützung für Pointer wäre ein klarer Rückschritt.

  10. Re: Programmiersprachen C und C++ == Grundsätzliches Problem

    Autor: BRDiger 11.05.14 - 19:27

    @nolonar

    Sehe ich genauso aber viele sehen in Pointern den Teufel und die Ursache aller Sicherheitslücken. Ich find in C echt cool, dass *alles* nur Speicher ist und man fast beliebig darauf zugreifen kann. Viele mögen das nicht, weil man dadurch auch viel Mist bauen kann aber man kann auch verdammt cooles Zeug damit machen.

    Nur mal ein Beispiel: Ich denke jeder der mal einfach verkettete Listen implementiert hat weiß dass man in der "append"-Funktion prüfen muss ob der head == NULL ist für den Fall dass die Liste leer ist. Mein Kumpel nannte das ein "branch-prediction-nightmare", was auch definitiv wahr ist, denn die Liste ist meistens nicht leer (!!!) und trotzdem wird jedes mal dieses If berechnet. In C ist es (mit container_of() ) möglich eine Adresse *vor* den head zu springen und dann diese Adresse mit "->next" zu derefenzieren was wiederum nur der head ist aber eben ohne Fallunterscheidung. Man konnte sich das "if (head == NULL) { head = new; return }" komplett sparen. Das bringt eine nicht unerhebliche Performanzverbesserung. Manch einer würde sagen "peanuts" aber schlecht ist es doch nicht!

    *Sowas* geht nur in Sprachen wie C. Man kann sich darüber streiten wie "wichtig" das ist aber es zeigt klar die "Mächtigkeit" (abzugrenzen von "Mächtigkeit" aus der Berechenbarkeitstheorie) dieser Sprache.



    1 mal bearbeitet, zuletzt am 11.05.14 19:28 durch BRDiger.

  11. Re: Programmiersprachen C und C++ == Grundsätzliches Problem

    Autor: LucifersChild 11.05.14 - 19:32

    Für die Systemprogrammierung sind die Anforderungen andere, wie bei der Anwendungsentwicklung. Da sollte einem die Sprache Arbeit abnehmen und eben nicht erlauben im Speicher herumzuspielen, weil man dabei in der Regel viele Fehler machen kann und der Code dadurch auch nicht unbedingt übersichtlicher wird.

    Dass in C keine richtigen Strings implementiert wurden, ist rückblickend einfach Pech und kein cooles Feature.

  12. Re: Programmiersprachen C und C++ == Grundsätzliches Problem

    Autor: BRDiger 11.05.14 - 20:21

    LucifersChild schrieb:
    --------------------------------------------------------------------------------
    > Für die Systemprogrammierung sind die Anforderungen andere, wie bei der
    > Anwendungsentwicklung. Da sollte einem die Sprache Arbeit abnehmen und eben
    > nicht erlauben im Speicher herumzuspielen, weil man dabei in der Regel
    > viele Fehler machen kann und der Code dadurch auch nicht unbedingt
    > übersichtlicher wird.
    >
    > Dass in C keine richtigen Strings implementiert wurden, ist rückblickend
    > einfach Pech und kein cooles Feature.

    Wieso erlaubt man dem Programmierer dann überhaupt irgendetwas? Am besten gar nicht programmieren - man macht ja eh nur Fehler.
    "Fehler machen kann" - auf *kann* liegt hier die Betonung.

    Was sind denn "richtige Strings"? Beziehungsweise: wie hättest du sie denn in C implementiert? Vielleicht als struct (mit "char *data; unsigned int size") mit dafür vorgesehenen Funktionen aber dann hast du eben das Problem dass die struct auch anderweitig verändert werden kann. Man büßt eben auch einiges an Freiheit ein. Gerade diese "immutable" Strings in manchen Sprachen finde ich zum Kotzen und ich ziehe dann lieber die unschönen char-pointer vor.

  13. Re: Programmiersprachen C und C++ == Grundsätzliches Problem

    Autor: 0xDEADC0DE 12.05.14 - 10:15

    BRDiger schrieb:
    --------------------------------------------------------------------------------
    > @muh3:
    >
    > Deine Kritik an C kann ich irgendwie nicht ganz nachvollziehen - nenne doch
    > mal noch ein paar Funktionen außer printf(). Das Problem mit printf() tritt
    > übrigens nur bei falscher Benutzung auf. (format string vulnerability)

    Ich bin zwar keine Kuh, aber ich sag dazu auch mal muh:
    Pointer und Arrays machen in C(++) schon vieles "kaputt". Ich hab vor längerer Zeit mal einen Fehler dieser Art in i6comp behoben und hab mich ehrlich gesagt gewundert, wie der Code vorher funktionieren konnte...

  14. Re: Programmiersprachen C und C++ == Grundsätzliches Problem

    Autor: bstea 12.05.14 - 10:38

    Lies dich erstmal ein was der Unterschied zwischen Referenzen und Pointer sind, den scheinst du nicht verstanden zu haben. Weshalb deine Beispiele gelinde gesagt Blödsinn sind wenn sie versuchen Referenzen erklären zu wollen.

    --
    Erst wenn der letzte Baum gefällt, der letzte Fluss gestaut und der letzte Fisch gefangen ist, werdet ihr feststellen, dass man Biber nicht essen kann!

  15. Re: Programmiersprachen C und C++ == Grundsätzliches Problem

    Autor: bernd71 12.05.14 - 11:06

    C in Bibliotheken ist ja auch beliebt da man diese in vielen Umgebungen einsetzen kann. Was nützt einem eine in einer Programmiersprache geschriebenen Bibliothek, die ich in andere Sprachen nicht einbinden kann. Ist das bei ADA möglich?

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. Schwarz Dienstleistung KG, Raum Neckarsulm
  2. ITEOS, Stuttgart
  3. Westermann Gruppe, Braunschweig
  4. TOPdesk Deutschland GmbH, Kaiserslautern

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. (-67%) 19,99€
  2. 4,99€
  3. 23,99€
  4. (-55%) 4,50€


Haben wir etwas übersehen?

E-Mail an news@golem.de


Verkehr: Das Kaltstart-Dilemma der Autos mit Hybridantrieb
Verkehr
Das Kaltstart-Dilemma der Autos mit Hybridantrieb

Bei Hybridautos und Plugin-Hybriden kommt es häufiger zu Kaltstarts als bei normalen Verbrennungsmotoren - wenn der Verbrennungsmotor ausgeht und der Elektromotor das Auto durch die Stadt schiebt. Wie schnell lässt sich der Katalysator vorwärmen, damit er Abgase dennoch gut reinigen kann?
Von Rainer Klose

  1. Elektromobilität Umweltbonus gilt auch für Jahreswagen
  2. Renault City K-ZE Dacia plant City-Elektroauto
  3. Elektroautos EU-Kommission billigt höheren Umweltbonus

Generationenübergreifend arbeiten: Bloß nicht streiten
Generationenübergreifend arbeiten
Bloß nicht streiten

Passen Generation Silberlocke und Generation Social Media in ein IT-Team? Ganz klar: ja! Wenn sie ihr Wissen teilen, kommt am Ende sogar Besseres heraus. Entscheidend ist die gleiche Wertschätzung beider Altersgruppen und keine Konflikte in den altersgemischten Teams.
Von Peter Ilg

  1. Frauen in der Technik Von wegen keine Vorbilder!
  2. Arbeit Warum anderswo mehr Frauen IT-Berufe ergreifen
  3. Arbeit Was IT-Recruiting von der Bundesliga lernen kann

Videostreaming: Was an Prime Video und Netflix nervt
Videostreaming
Was an Prime Video und Netflix nervt

Eine ständig anders sortierte Watchlist, ein automatisch startender Stream oder fehlende Markierungen für Aboinhalte: Oft sind es nur Kleinigkeiten, die den Spaß am Streaming vermiesen - eine Hassliste.
Ein IMHO von Ingo Pakalski

  1. WhatsOnFlix Smartphone-App für bessere Verwaltung der Netflix-Inhalte
  2. Netflix Staffel-2-Trailer zeigt Cyberpunk-Welt von Altered Carbon
  3. Videostreaming Netflix musste Night of the Living Dead entfernen

  1. Startup: Rückenschmerzen-App Kaia verzwölffacht ihren Preis
    Startup
    Rückenschmerzen-App Kaia verzwölffacht ihren Preis

    Eine E-Health-App hat am Montag drastisch höhere Preise eingeführt, obwohl sie mit 96 Euro jährlich schon viel kostete: Ab jetzt zahlen Neukunden 99 Euro - aber nicht im Jahr, sondern pro Monat. Dafür könne Kaia bei chronischen Rückenschmerzen wirklich helfen, glauben nicht nur viele Krankenkassen.

  2. Bundesnetzagentur: Telefónica erhält Millionenstrafe wegen schlechten Netzes
    Bundesnetzagentur
    Telefónica erhält Millionenstrafe wegen schlechten Netzes

    Die Bundesnetzagentur wird Telefónica Deutschland wohl zu einer Strafe im zweistelligen Millionenbereich verurteilen. Der Netzbetreiber nennt dies "kontraproduktiv für die Netzversorgung in Deutschland".

  3. Konsolen: Microsoft bestätigt 12 Teraflops für Xbox Series X
    Konsolen
    Microsoft bestätigt 12 Teraflops für Xbox Series X

    Nun ist es offiziell: Die GPU der Xbox Series X schafft eine Leistung von 12 Teraflops - ungefähr das Doppelte der Xbox One X. Damit treffen einige Leaks zu, außerdem hat der zuständige Manager Phil Spencer eine Reihe weiterer Neuheiten vorgestellt.


  1. 18:37

  2. 17:31

  3. 16:54

  4. 16:32

  5. 16:17

  6. 15:47

  7. 15:00

  8. 15:00