1. Foren
  2. Kommentare
  3. Internet
  4. Alle Kommentare zum Artikel
  5. › Programmiersprachen: Ada und Spark…

Tabelle Unterschiede

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


  1. Tabelle Unterschiede

    Autor: nuclear 01.09.20 - 12:52

    Na ja. Irgendwie sehen mir die meisten Beispiele sehr an den Haaren herbeigezogen aus.

    Bei der IF-Abfrage kann man einfach Klammern nehmen. Dann kann man das auch leicht darstellen. Aber vor allem das goto habe ich in C eigentlich nie gesehen.

    Bei der Case-Abfrage kann man Fallthrough sinnvoll einsetzen. Ob da das implizite besser ist weiß ich nicht.

    Wo jetzt der Vorteil bei = und == oder := und = liegt erschließt sich mir ebenfalls nicht. Für jemanden der neu einsteigt ok, aber das sollte ja kein Problem sein.

    Und so weiter.

    Klar kann man damit die Fehler was verhindern, aber dann schränkt man die Sprache doch ein. Ich bin eher der Meinung der Code sollte gründlich getestet werden, jede Funktion für sich, dann findet man auch solche Fehler.

  2. Re: Tabelle Unterschiede

    Autor: apoth90 01.09.20 - 13:06

    Also es passiert einfach sehr oft, dass man anstatt "if(x == 5)" aus Versehen "if(x = 5)" schreibt. Der Compiler schluckt es, und wenn man keinen Unit Test hat, der es darauf ansetzt, den entsprechenden if-body nicht auszuführen, wird man es auch eine Weile lang nicht merken. Und wer hat schon 100% Testcoverage.
    Auch optisch ist es nicht einfach zu erkennen, vor allem wenn sich die Fehlersuche in die erschöpfteren Arbeitsstunden zieht.

    Ich sehe es natürlich ein, dass man solche Zuweisungen gern nutzt, beispielsweise bei "while(str = readline(f))", aber es ist wirklich ein alltäglicher Fallstrick. Allein wenn man einen Funktionsaufruf anstatt eines Operators benutzen müsste, wäre schon viel geholfen, weil der Fehler dann nicht mehr versehentlich passieren kann.

  3. Re: Tabelle Unterschiede

    Autor: MrTridac 01.09.20 - 13:17

    Am schönsten zeigt der Satz: "Viele Programmierer erwarten hier das Resultat 0.75 ...", an welche Zielgruppe der Autor denkt.
    Nämlich an Anfänger und Gelegenheitsprogrammierer.
    Jeder ernstzunehmende Programmierer sieht auf den ersten Blick, dass hier zwei Integer-Werte dividiert werden, was SELBSTVERSTÄNDLICH zu einem Integer Ergebnis führt.

    Auch Beispiel 1 ist Unsinn. Kein C Programmierer stellt sich hier die Frage welches goto zum if() gehört.
    Die Aussage: "In C ist nicht klar ..." ist völlig Falsch, da sehr genau definiert ist, wie die Statements evaluiert werden.
    Nur jemand der kein C programmiert, könnte hier verwirrt sein.

    Außerdem:
    i++ ist Problematisch ???????
    Was zum Geier ist an i++ unverständlich oder unleserlich oder gefährlich??

  4. Re: Tabelle Unterschiede

    Autor: captain_spaulding 01.09.20 - 13:19

    Bei z.B. MISRA-C sind die genannten Konstrukte sowieso verboten. Und das lässt sich dann auch automatisch checken.
    Die genannten Probleme sind eher Nebensächlichkeiten. C hat viel tiefgreifendere Probleme die sich nicht so einfach vermeiden lassen.

  5. Re: Tabelle Unterschiede

    Autor: franzropen 01.09.20 - 13:33

    Ich schätze der Unterscheid liegt in kann vs muss.
    Du kannst in C Klammern setzen aber du musst in Ada das If-Statement mit end if beenden.
    Wenn Ada keine Zuweisung der If_Bedingung erlaubt, wäre das auch das eigentliche Sicherheitsfeature und nicht unbedingt dass es einen anderen Zuweisungsoperator verwendnet.
    Hier liegt halt der Vorteil darin, dass es unwahrscheinlicher ist eine ungewollte Zuweisung zu machen, da ich explizit := schreiben muss.
    Das zweite Gleichheitszeichen in C kann man leicht vergessen.

  6. Re: Tabelle Unterschiede

    Autor: Max Level 01.09.20 - 13:34

    nuclear schrieb:
    --------------------------------------------------------------------------------
    > Na ja. Irgendwie sehen mir die meisten Beispiele sehr an den Haaren
    > herbeigezogen aus.

    Die sind bloß einfach, damit man die Änderungen exemplarisch darstellen kann.

    > Bei der IF-Abfrage kann man einfach Klammern nehmen. Dann kann man das auch
    > leicht darstellen. Aber vor allem das goto habe ich in C eigentlich nie
    > gesehen.
    >
    > Bei der Case-Abfrage kann man Fallthrough sinnvoll einsetzen. Ob da das
    > implizite besser ist weiß ich nicht.
    >
    > Wo jetzt der Vorteil bei = und == oder := und = liegt erschließt sich mir
    > ebenfalls nicht. Für jemanden der neu einsteigt ok, aber das sollte ja kein
    > Problem sein.

    Natürlich "kann" man das. Es geht aber bei "safety" immer um Fehlerausschlüsse der Art "kann gerade nicht mehr passieren". Safety ist eine Art Risikominimierung, es geht bezüglich Software immer(!) um die Reduzierung systematischer Fehler (andere gibts nicht). Deswegen macht man 4-Augen-Prinzipien etc. Weil man weiß, dass Fehler nur Statistik ist: In jedem Code ab bestimmter Größe verstecken sich welche, und zwar egal wie gut der Programmierer ist.

    > Klar kann man damit die Fehler was verhindern, aber dann schränkt man die
    > Sprache doch ein. Ich bin eher der Meinung der Code sollte gründlich
    > getestet werden, jede Funktion für sich, dann findet man auch solche
    > Fehler.

    Nein, findet man nicht. Sonst gäbs ja schon keine Fehler mehr. Natürlich wird der Code auch gründlich getestet, aber sicherheitstechnisch ist das Beste, was man machen kann, der Ausschluss von Fehlern. Und genau auf sowas zielen diese Sprachen, die MISRA-Regeln und so weiter. Weil es ja nun auch nichts hilft, erst nach dem Auftreten von Fehlern auf unfähige Leute zu schimpfen, denn Fehler passieren auch den Besten.
    Ist ein bisschen wie in "Wenn mal die ganzen Idioten so gut fahren würden wie ich, dann gäbs auch keine Unfälle". Doch, passiert. Auch bei Apple. Und ich glaube kaum, dass die da so viele unfähige Leute an den Code vom iOS lassen ;)

  7. Re: Tabelle Unterschiede

    Autor: earshp 01.09.20 - 13:37

    nuclear schrieb:
    --------------------------------------------------------------------------------
    > Na ja. Irgendwie sehen mir die meisten Beispiele sehr an den Haaren
    > herbeigezogen aus.
    >
    > Bei der IF-Abfrage kann man einfach Klammern nehmen. Dann kann man das auch
    > leicht darstellen. Aber vor allem das goto habe ich in C eigentlich nie
    > gesehen.

    Hallo,

    das ist kein konstruiertes Beispiel, sondern die zwei "goto fails" waren eine schwere Lücke in Apples TLS Bibliothek.

    Ich kann keine Links posten, aber Infos dazu sind leicht zu finden (Suchbegriffe: Apple's SSL/TLS bug ImperialViolet oder einfach "goto fail").

    Auch wenn es trivial erscheint, solche und ähnliche Fehler gibt es leider immer wieder, auch in sicherheitsrelevanter Software.

    Ein "goto" um z.B. ans Ende einer Funktion zu springen und Ressourcen aufzuräumen, ist übrigens nach meiner Erfahrung in C einigermaßen verbreitet, aber ich denke darum gehts bei dem Bug ja eigentlich gar nicht.

  8. Re: Tabelle Unterschiede

    Autor: tritratrulala 01.09.20 - 13:40

    apoth90 schrieb:
    --------------------------------------------------------------------------------
    > Also es passiert einfach sehr oft, dass man anstatt "if(x == 5)" aus
    > Versehen "if(x = 5)" schreibt. Der Compiler schluckt es, und wenn man
    > keinen Unit Test hat, der es darauf ansetzt, den entsprechenden if-body
    > nicht auszuführen, wird man es auch eine Weile lang nicht merken. Und wer
    > hat schon 100% Testcoverage.

    Diese Syntax-Doppeldeutigkeit ist eine klare Schwäche von C-artigen Sprachen, aber jeder vernünftige, aktuelle Compiler (also clang oder gcc) warnt hier, wenn man die Standard-Warnings aktiviert.

  9. Re: Tabelle Unterschiede

    Autor: Max Level 01.09.20 - 13:40

    MrTridac schrieb:
    --------------------------------------------------------------------------------
    > Am schönsten zeigt der Satz: "Viele Programmierer erwarten hier das
    > Resultat 0.75 ...", an welche Zielgruppe der Autor denkt.
    > Nämlich an Anfänger und Gelegenheitsprogrammierer.
    > Jeder ernstzunehmende Programmierer sieht auf den ersten Blick, dass hier
    > zwei Integer-Werte dividiert werden, was SELBSTVERSTÄNDLICH zu einem
    > Integer Ergebnis führt.

    Das stimmt so nicht, das ist compilerabhängig. Hab sowas selbst mal gewartet. Das Programm lief genau, wie es sollte, dann wurde der Compiler gewechselt (eine Nebenversion höher) und plötzlich war da irgendwo was faul. Es zeigte sich: Der alte Compiler hat erkannt, was *gemeint* war, hat erst auf float gecastet und dann dividiert. Der neue hat den Cast später durchgeführt und dann kam da natürlich Mist raus.

    Punkt ist: Es geht um Safety. Wenn man da hinterher sagen kann "Mimimi, der schlechte Programmierer, also mir wäre das ja nicht passiert" ist es schon viel viel zu spät, denn der Schaden ist schon da. Safety stützt sich gerade nicht auf "Der Mensch ist shcon gut genug, da passiert nix" sondern auf "Auch der beste Mensch macht statistisch gesehen Fehler, wir müssen welche davon ausschließen können".

    > Auch Beispiel 1 ist Unsinn. Kein C Programmierer stellt sich hier die Frage
    > welches goto zum if() gehört.
    > Die Aussage: "In C ist nicht klar ..." ist völlig Falsch, da sehr genau
    > definiert ist, wie die Statements evaluiert werden.
    > Nur jemand der kein C programmiert, könnte hier verwirrt sein.

    Mag sein. Ist aber egal: Es geht um die Vermeidung systematischer Fehler. Dieser da wäre einer. Es geht nicht um "Der Programmierer muss das sehen, sonst ist er unfähig", das hilft doch nichts, der Fehler ist weiterhin möglich. Mit "Sowas geht erst gar nicht" kanns nicht auftreten.

  10. Re: Tabelle Unterschiede

    Autor: George99 01.09.20 - 14:07

    nuclear schrieb:
    --------------------------------------------------------------------------------
    > Na ja. Irgendwie sehen mir die meisten Beispiele sehr an den Haaren
    > herbeigezogen aus.

    Ja, sehe ich genauso. Der Autor wollte hier für eine Exotensprache wie Ada trommeln und musste dazu irgendwelche doch arg kosntruierte Beispiele sammeln, die C schlecht aussehen lassen sollten.

    Bei Dingen wie if(a=b) warnt jeder moderne Compiler und wenn du tatsächlich a=b und nicht a==b gemeint hast, musst du ein zusätzliches Klammernpaar herum setzen if((a=b)) , um dem Compiler mitzuteilen, dass du hier eine Zuweisung mit Prüfung auf ungleich Null wolltest und wirklich keinen Vergleich.

    > leicht darstellen. Aber vor allem das goto habe ich in C eigentlich nie
    > gesehen.

    Ich benutze ab und zu goto, weil es kein continue-Statement zu einer höheren Schleife in C gibt.

    Beispiel:
    [code]
    for (a = ...) {
    for (b = ...) {
    ...
    if (Abbruchbedingung...) goto continue_a;
    ...
    }
    code();
    ....
    continue_a:;
    }
    [/code]

  11. Re: Tabelle Unterschiede

    Autor: EWCH 01.09.20 - 14:39

    > Also es passiert einfach sehr oft, dass man anstatt "if(x == 5)" aus
    > Versehen "if(x = 5)" schreibt. Der Compiler schluckt es

    wenn bei gcc '-Wall' an ist (und das ist es eigentlich immer), dann kommt das hier:

    warning: suggest parentheses around assignment used as truth value

  12. Re: Tabelle Unterschiede

    Autor: franzropen 01.09.20 - 14:57

    D.h. du musst nicht nur vernünftig programmieren können, sondern auch alle Features des verwendeten Compilers kennen. bei OpenSource könnte es dann schwierig werden, weil sich jemand vielleicht die Quellen zieht und selbst compiliert.
    Wenn der dann den "falschen" Compiler hat ...
    Wenn man die Sicherheit einen Schritt davor erhöhen kann, warum nicht?

  13. Re: Tabelle Unterschiede

    Autor: EWCH 01.09.20 - 15:36

    > D.h. du musst nicht nur vernünftig programmieren können, sondern auch alle
    > Features des verwendeten Compilers kennen. bei OpenSource könnte es dann
    > schwierig werden, weil sich jemand vielleicht die Quellen zieht und selbst
    > compiliert.
    > Wenn der dann den "falschen" Compiler hat ...
    > Wenn man die Sicherheit einen Schritt davor erhöhen kann, warum nicht?

    Wer seinen Compiler von Hand aufruft oder seine Makefiles selber schreibt sollte die wichtigsten Parameter kennen. Ohne Optimierungen ist das Binary sonst auch deutlich langsamer.
    Die Mehrzahl der Softwareentwickler duerfte aber Entwicklungsumgebungen oder zumindest Tools wie cmake, qmake, automake, ... verwenden.
    Und es ist die Aufgabe des Entwicklers seinen Code zu pruefen, nicht die des Anwenders.

  14. Re: Tabelle Unterschiede

    Autor: WeitWeitWeg 01.09.20 - 20:02

    apoth90 schrieb:
    --------------------------------------------------------------------------------
    > Also es passiert einfach sehr oft, dass man anstatt "if(x == 5)" aus
    > Versehen "if(x = 5)" schreibt. Der Compiler schluckt es, und wenn man
    > keinen Unit Test hat,

    Der compiler gibt eine Warnmeldung aus. Ansonsten ist es best practice in C bei if-statements immer die Konstante vorne zu schreiben. Dadurch kriegt man diesen Ausdruck nicht mal kompiliert "if(5 = x)".

  15. Re: Tabelle Unterschiede

    Autor: captain_spaulding 01.09.20 - 23:25

    WeitWeitWeg schrieb:
    --------------------------------------------------------------------------------
    > Der compiler gibt eine Warnmeldung aus. Ansonsten ist es best practice in C
    > bei if-statements immer die Konstante vorne zu schreiben. Dadurch kriegt
    > man diesen Ausdruck nicht mal kompiliert "if(5 = x)".
    Yoda notation nennt sich das. Ist aber schlecht zu lesen und macht kaum jemand. Zu recht! Ist auch überflüssig Compiler und/oder Code-Analyse-Tools bei sowas warnen. Bei MISRA ist es eh verboten.

  16. Re: Tabelle Unterschiede

    Autor: ksson 02.09.20 - 00:32

    Hallo, ich bin der Autor des Artikels.

    Die Tabelle ist vielleicht nicht so gelungen (gebe ich zu), aber konstruiert ist da nichts.

    Das "goto fail" Beispiel ist wie schon erwähnt ein echter Bug in Apple's SSL Implementation (2014). Sicher, wenn sich ein Programmierer die Frage stellt "wozu gehört das zweite goto fail"?, dann sieht er das Problem. Aber der Programmierer (und der Reviewer!) haben sich die Frage eben offensichtlich nicht gestellt, sondern nur schnell drübergeschaut. Andere Sprachen versuchen solche Situationen zu vermeiden.

    Das Problem mit der Zuweisung "=" in C ist vor allem, dass sie einen Rückgabewert hat, und dass es in C sehr oft passiert, dass eine Zuweisung in einem if-Statement verwendet wird. Würde der Compiler da warnen, gäbe es viele false positives ... Im Artikel gibt es dazu auch einen Link, wo "=" statt "==" verwendet wurde, um (zu versuchen) eine Backdoor in den Linux-Kernel einzuschleusen.

    Jedes einzelne Problem für sich ist auch nicht so schlimm, und einige Probleme lassen sich mit Compiler-Warnings und statischen Analysen vermeiden (zB das erwähnte MISRA C), aber alles zusammen bringt einfach zu viele Fehlerquellen.

    C ist einfach nicht mehr zeitgemäß für kritische Software.

  17. Re: Tabelle Unterschiede

    Autor: MarcusK 02.09.20 - 07:47

    ksson schrieb:
    --------------------------------------------------------------------------------
    > Hallo, ich bin der Autor des Artikels.
    >
    > Die Tabelle ist vielleicht nicht so gelungen (gebe ich zu), aber
    > konstruiert ist da nichts.
    >
    > Das "goto fail" Beispiel ist wie schon erwähnt ein echter Bug in Apple's
    > SSL Implementation (2014). Sicher, wenn sich ein Programmierer die Frage
    > stellt "wozu gehört das zweite goto fail"?, dann sieht er das Problem. Aber
    > der Programmierer (und der Reviewer!) haben sich die Frage eben
    > offensichtlich nicht gestellt, sondern nur schnell drübergeschaut. Andere
    > Sprachen versuchen solche Situationen zu vermeiden.
    Das liegt aber auch mehr oder weniger an der Disziplin von Entwickler, bei und wird jedes IF mit eine { } gemacht, auch wenn es nur eine Zeile ist. Damit Würde der Code schon dadurch auffallen, das es keine klammern gibt.

    > Das Problem mit der Zuweisung "=" in C ist vor allem, dass sie einen
    > Rückgabewert hat, und dass es in C sehr oft passiert, dass eine Zuweisung
    > in einem if-Statement verwendet wird. Würde der Compiler da warnen, gäbe es
    > viele false positives …
    eine Warum kann gar nicht "false positives" sind. Denn ist es ist nur eine Warnung. Und ja aktuelle Compiler warnen. Wenn man den Code wirklich so will, muss man das ganze noch mal Klammern.

    > statt "==" verwendet wurde, um (zu versuchen) eine Backdoor in den
    > Linux-Kernel einzuschleusen.
    Für Backdoors wird es wohl in jeder Sprache Möglichkeiten geben.

    > C ist einfach nicht mehr zeitgemäß für kritische Software.
    C mit unerfahren oder undisziplinierten Entwicklern.

    Perl zeigt es schön, man kann damit unlesbaren und unwartbaren Code schreiben, genauso kann man mit ein paar eigenen Regeln sehr sauberen Code schreiben.
    Genauso bei C, wenn man nicht alles Spitzfindigkeiten der Sprache ausnutzt und lieber eine zeile mehr schreibt, kann genauso sicheren Code rauskommen.

    Wie oft sind denn wirklich Fehler die mit der Sprache zu tun haben in kritischen Fällen vorhanden im vergleich zu Fehler in der Logik? Die meisten Bug in OpenSSL klingen mehr wie Logikfehler und die sind in jeder Sprache gleich

  18. Re: Tabelle Unterschiede

    Autor: MrTridac 02.09.20 - 10:15

    Max Level schrieb:
    --------------------------------------------------------------------------------
    > MrTridac schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > zwei Integer-Werte dividiert werden, was SELBSTVERSTÄNDLICH zu einem
    > > Integer Ergebnis führt.
    >
    > Es zeigte sich: Der alte Compiler hat erkannt, was *gemeint* war, hat
    > erst auf float gecastet und dann dividiert. Der neue hat den Cast später
    > durchgeführt und dann kam da natürlich Mist raus.
    >
    > Punkt ist: Es geht um Safety [...] stützt sich gerade
    > nicht auf "Der Mensch ist shcon gut genug, da passiert nix" sondern auf
    > "Auch der beste Mensch macht statistisch gesehen Fehler, wir müssen welche
    > davon ausschließen können".

    Das ist richtig, aber in JEDER Programmiersprache machen Menschen Fehler.
    Wenn sie Die aus dem Beispiel nicht machen, machen sie andere.
    Am Ende kommt es IMMER auf die Fähigkeiten des Programmierers an.
    Egal in welcher Sprache. Daher ist C-bashing unfair.

    > Es geht um die Vermeidung systematischer Fehler.
    > Es geht nicht um "Der Programmierer muss das sehen,
    > sonst ist er unfähig", das hilft doch nichts, der Fehler ist weiterhin
    > möglich.

    Systematische Fehler gibt's immer. Vermeidet man Einen, tut sich ein Anderer auf.
    Es ist illusorisch, zu versuchen, alle Fehler zu verhindern.
    Es gibt einen Punkt ab dem der Programmierer eben wissen muss was er tut.
    Programmieren ist Ingenieursarbeit, nicht rumdaddeln und hoffen der Compiler wird's schon merken.
    Wenn diese Einstellung dann aber dazu führt, dass Werkzeuge und Handlungsspielraum eingeschränkt werden, verschlechtert das die Programm-Qualität als ganzes.

  19. Re: Tabelle Unterschiede

    Autor: captain_spaulding 02.09.20 - 10:21

    MarcusK schrieb:
    --------------------------------------------------------------------------------
    > > C ist einfach nicht mehr zeitgemäß für kritische Software.
    > C mit unerfahren oder undisziplinierten Entwicklern.

    Die Erfahrung zeigt: In jeder nicht-trivialen Software sind C-spezifische Fehler drin die in anderen Sprachen nicht möglich sind.
    Daraus schließen wir: In jedem Projekt gibt es unerfahrene oder undisziplinierte Entwickler.

    Wer nun ein C-Projekt startet und Fehler vermeiden will indem er nur erfahrene und disziplinierte Entwickler einstellt, ist schon ziemlich mutig.
    "Wir machen im Prinzip genau das gleiche wie alle Projekte zuvor aber bei uns wird es anders laufen. Denn wir sind besser."

  20. Re: Tabelle Unterschiede

    Autor: MarcusK 02.09.20 - 10:39

    captain_spaulding schrieb:
    --------------------------------------------------------------------------------
    > MarcusK schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > > C ist einfach nicht mehr zeitgemäß für kritische Software.
    > > C mit unerfahren oder undisziplinierten Entwicklern.
    >
    > Die Erfahrung zeigt: In jeder nicht-trivialen Software sind C-spezifische
    > Fehler drin die in anderen Sprachen nicht möglich sind.

    man kann aus auch allgemein formulieren.

    In jeden Projekt sind Fehler drin, die mit einer anderen Sprache nicht möglich sind.

    Oder wie war das mit der Sicherheit von JAVA?

  1. Thema
  1. 1
  2. 2

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. Universität Potsdam, Potsdam
  2. Schaeffler Digital Solutions GmbH, Chemnitz
  3. Hays AG, Stuttgart
  4. Bundesamt für Sicherheit in der Informationstechnik, Bonn

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. (u. a. Sam & Max Hit the Road für 1,25€ Maniac Mansion für 1,25€, The Secret of Monkey...
  2. 10,49€
  3. 4,99€
  4. gratis


Haben wir etwas übersehen?

E-Mail an news@golem.de


Apple: iPhone 12 bekommt Magnetrücken und kleinen Bruder
Apple
iPhone 12 bekommt Magnetrücken und kleinen Bruder

Das iPhone 12 ist mit einem 6,1-Zoll- und das iPhone 12 Mini mit einem 5,4-Zoll-Display ausgerüstet. Ladegerät und Kopfhörer fallen aus Gründen des Umweltschutzes weg.

  1. Apple iPhone 12 Pro und iPhone 12 Pro Max werden größer
  2. Apple iPhone 12 verspätet sich
  3. Back Tap iOS 14 erkennt Trommeln auf der iPhone-Rückseite

Shifoo: Golem.de startet Betatest seiner Karriere-Coaching-Plattform
Shifoo
Golem.de startet Betatest seiner Karriere-Coaching-Plattform

Beratung, die IT-Profis in Job & Karriere effizient und individuell unterstützt: Golem.de startet die Video-Coaching-Plattform Shifoo. Hilf uns in der Betaphase, sie für dich perfekt zu machen, und profitiere vom exklusiven Angebot!

  1. Stellenanzeige Golem.de sucht Verstärkung für die Redaktion
  2. Stellenanzeige Golem.de sucht CvD (m/w/d)
  3. In eigener Sache Die 24-kernige Golem Workstation ist da

Tutorial: Was ein On Screen Display alles kann
Tutorial
Was ein On Screen Display alles kann

Werkzeugkasten Viele PC-Spieler schwören auf ein OSD. Denn damit lassen sich Limits erkennen, die Bildqualität verbessern und Ruckler verringern.
Von Marc Sauter