1. Foren
  2. Kommentare
  3. Security-Forum
  4. Alle Kommentare zum Artikel
  5. › Security: Glibc-Bugfix machte…

Tja, C halt ...

Neue Foren im Freiraum! Raumfahrt und freie Software haben jetzt einen Platz, die Games tummeln sich jetzt alle in einem Forum.
  1. Thema

Neues Thema Ansicht wechseln


  1. Tja, C halt ...

    Autor: spiegelneuron 17.08.21 - 13:44

    k.w.T.

  2. Re: Tja, C halt ...

    Autor: caldeum 17.08.21 - 13:53

    Ja ab einer bestimmten Komplexität bzw. Tiefe nervt mich das incref/decref/alloc/free in C auch. Aber es ist nunmal DIE Systemprogrammiersprache die auch nach 50 Jahren nicht vom Thron gestoßen wurde wegen der vielen Freiheiten die man hat.

  3. Re: Tja, C halt ...

    Autor: picaschaf 17.08.21 - 14:24

    Das hat mit der Sprache selbst recht wenig zu tun.

  4. Re: Tja, C halt ...

    Autor: bionade24 17.08.21 - 16:02

    Die CVE-Liste der Stdlib von Rust möchte man sich auch nicht angucken. Sobald unsafe im Spiel ist, das gleiche (von Rust) ungelöste deasaster.

    Bitte BBCode nutzen und nicht einfach Links reinpasten, wir sind hier schließlich in einem IT-Forum!

  5. Re: Tja, C halt ...

    Autor: caldeum 17.08.21 - 21:29

    bionade24 schrieb:
    --------------------------------------------------------------------------------
    > Die CVE-Liste der Stdlib von Rust möchte man sich auch nicht angucken.
    > Sobald unsafe im Spiel ist, das gleiche (von Rust) ungelöste deasaster.
    Was in der GLibc ziemlich oft der Fall sei dürfte da der Kernel halt in C geschrieben wurde und man um unsafe dann nicht herum kommt.

  6. Re: Tja, C halt ...

    Autor: schily 17.08.21 - 23:06

    Schlechte Programmierer schaffen es in jeder Sprache gefährlichen Code zu schreiben und die Programmiersprache des Kerns ist irrelevant, weil er eine sichere Schnittstelle liefert.

  7. Re: Tja, C halt ...

    Autor: Walter Plinge 18.08.21 - 19:19

    schily schrieb:
    --------------------------------------------------------------------------------
    > Schlechte Programmierer schaffen es in jeder Sprache gefährlichen Code zu
    > schreiben und die Programmiersprache des Kerns ist irrelevant, weil er eine
    > sichere Schnittstelle liefert.

    Soll das ein Argument sein? Schlechte Köche werden auch in einer perfekten Küche kein gutes Essen hinbekommen. Müssen deshalb gute Köche mit Kesseln und offenem Feuer arbeiten?

    Es ist doch wohl unbestritten, dass moderne Sprachen wie Rust oder Go gegenüber C viele Vorteile haben, angefangen beim einheitlichen Buildsystem über eine bessere, weil (teil-) automatisierte Speicherverwaltung bis hin zur Parallelisierung. Nur weil man in diesen modernen Sprachen auch Mist machen kann, heißt das ja nicht, dass alle ewig auf dem alten Mist sitzen bleiben müssen.

    Ich habe inzwischen 25 Jahre C-Programmiererfahrung. Trotzdem unterlaufen mir mehr oder weniger regelmäßig (Flüchtigkeits-)Fehler, die in anderen Sprachen so entweder gar nicht möglich sind, oder spätestens vom Compiler erkannt werden. Umgekehrt hatte ich zum Beispiel nie das Problem mit dem Speichermanagement des Rustcompilers „kämpfen“ zu müssen (wovon ja in vielen Foren berichtet wird). Die zwei oder drei Mal wo er bei mir gemeckert hat (in zwei kleinen 20000 Zeilen Projekten), musste ich letztlich zugeben, dass er recht hatte. Im Endeffekt ist dabei einfach besserer (und besser wartbarer) Code entstanden. Und welcher (gute) Entwickler würde das ablehnen wollen?

  8. Re: Tja, C halt ...

    Autor: FreiGeistler 18.08.21 - 20:21

    picaschaf schrieb:
    --------------------------------------------------------------------------------
    > Das hat mit der Sprache selbst recht wenig zu tun.

    Ich wundere mich trotzdem, weshalb man da alle Flexibilitaet in ein tool stopft und die nicht wenigstens nach architektur aufteilt.
    Und musl libc kann fast alles von glibc in simpler.



    1 mal bearbeitet, zuletzt am 18.08.21 20:29 durch FreiGeistler.

  9. Re: Tja, C halt ...

    Autor: FreiGeistler 18.08.21 - 20:29

    Walter Plinge schrieb:
    --------------------------------------------------------------------------------
    > Die zwei oder drei Mal wo er bei mir
    > gemeckert hat (in zwei kleinen 20000 Zeilen Projekten), musste ich
    > letztlich zugeben, dass er recht hatte.

    Heute, wo 20k loc als kleines Projekt gelten. Ich glaube, eher da liegt das Problem mit der Sicherheit.

  10. Re: Tja, C halt ...

    Autor: picaschaf 18.08.21 - 22:51

    FreiGeistler schrieb:
    --------------------------------------------------------------------------------
    > picaschaf schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Das hat mit der Sprache selbst recht wenig zu tun.
    >
    > Ich wundere mich trotzdem, weshalb man da alle Flexibilitaet in ein tool
    > stopft und die nicht wenigstens nach architektur aufteilt.
    > Und musl libc kann fast alles von glibc in simpler.

    Welche Funktionalität wird denn in ein Tool gestopft? Die C Library stellt Basisfunktionalität und das Interface zum Betriebssystem her, mehr nicht.
    Und musl, ulibc und Co. haben *gravierende* Einschränkungen ggü. der glibc. Man merkt sie nur nicht in jeder Anwendung.

  11. Re: Tja, C halt ...

    Autor: picaschaf 18.08.21 - 22:56

    FreiGeistler schrieb:
    --------------------------------------------------------------------------------
    > Walter Plinge schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Die zwei oder drei Mal wo er bei mir
    > > gemeckert hat (in zwei kleinen 20000 Zeilen Projekten), musste ich
    > > letztlich zugeben, dass er recht hatte.
    >
    > Heute, wo 20k loc als kleines Projekt gelten. Ich glaube, eher da liegt das
    > Problem mit der Sicherheit.

    20k LOC waren schon immer ein kleines Projekt wenn du nicht auf größere Frameworks wie zB. Qt setzt. Aber in Funktionalität pro k LOC müsstest du dann Teile des Frameworks streng genommen ebenso miteinrechnen auch wenn es "besserer" Code ist als selbstgeschrieben.

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. Backend Entwickler (m/w/d)
    DiMaBay GmbH, Berlin, Bayreuth (Home-Office möglich)
  2. IT Solutions Engineer Backend-Entwicklung (m/w/d)
    Schaeffler Technologies AG & Co. KG, Nürnberg
  3. Frontend-Entwickler:in
    LBD-Beratungsgesellschaft mbH, Berlin (Home-Office möglich)
  4. Software - Projektingenieur (m/w/d)
    Brückner Maschinenbau GmbH & Co. KG, Siegsdorf

Detailsuche


Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. 3,89€
  2. (u. a. Lust from Beyond für 11,99€, Song of Horror - Complete Edition für 14,99€, Treasure...
  3. 19,99€


Haben wir etwas übersehen?

E-Mail an news@golem.de


Vision 6 im Hands On: Gelungene neue E-Book-Oberklasse von Tolino
Vision 6 im Hands On
Gelungene neue E-Book-Oberklasse von Tolino

Die Tolino-Allianz hat dem neuen E-Book-Reader Vision 6 mehr Speicher und Geschwindigkeit spendiert. Das ergibt einen gelungenen E-Book-Reader.
Ein Hands-on von Ingo Pakalski

  1. Family Sharing Tolino erlaubt das Teilen digitaler Hörbücher

Radeon RX 6600 im Test: Die bisher günstigste Raytracing-Grafikkarte
Radeon RX 6600 im Test
Die bisher "günstigste" Raytracing-Grafikkarte

Mit der sparsamen Radeon RX 6600 lässt sich in 1080p gut spielen, für Raytracing-Grafik müssen aber bestimmte Punkte erfüllt sein.
Ein Test von Marc Sauter

  1. Radeon RX 5000 AMD-Treiber verbessert Leistung älterer Grafikkarten
  2. RDNA2-Grafikkarte Radeon RX 6600 XT ab 430 Euro lieferbar
  3. Radeon RX 6600 XT im Test Wenn die Unendlichkeit bei 1080p endet

Galaxy Z Flip 3 im Test: Wir wollen ja, dass es klappt
Galaxy Z Flip 3 im Test
Wir wollen ja, dass es klappt

Samsungs Flip 3 ist sehr gut verarbeitet und hat einen besser nutzbaren Außenbildschirm - trotzdem ist uns das Aufklappen immer noch eher lästig.
Ein Test von Tobias Költzsch

  1. Smartphone Samsung entfernt Werbung aus eigenen Apps
  2. Galaxy Watch 4 Classic im Test Samsungs Tempo plus Googles App-Auswahl
  3. Fotografie Samsung präsentiert 200-Megapixel-Sensor für Smartphones