Linkdump

Hier kann über allgemeine Themen diskutiert werden, die sonst in kein Forum passen.
Insbesondere über Szene, Games, Kultur, Weltgeschehen, Persönliches, Recht, Hard- und Software.
Benutzeravatar
Jonathan
Establishment
Beiträge: 2022
Registriert: 04.08.2004, 20:06
Kontaktdaten:

Re: Linkdump

Beitrag von Jonathan »

Ja, das meiste scheinen irgendwie kommerzielle Indie-Games aus dt. zu sein. Und dann verkommt so ein Forum natürlich schnell zu einem Advertisementboard für Shitty-Games. Naja.
Lieber dumm fragen, als dumm bleiben!
Benutzeravatar
Krishty
Establishment
Beiträge: 7929
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Linkdump

Beitrag von Krishty »

Als Ergänzung zur Diskussion über Undefined Behavior, die wir letztens hatten: GCC undefined behaviors are getting wild

Nice, wie weit die Optimierung mittlerweile gehen kann!
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Schrompf
Moderator
Beiträge: 4552
Registriert: 25.02.2009, 23:44
Benutzertext: Lernt nur selten dazu
Echter Name: Thomas Ziegenhagen
Wohnort: Dresden
Kontaktdaten:

Re: Linkdump

Beitrag von Schrompf »

Ich versteh's nicht, ehrlich gesagt. 0x1fffe00 oder so durch 0xffff ist doch save? Was soll denn da noch kommen?
Häuptling von Dreamworlds. Baut an was Neuem. Hilft nebenbei nur höchst selten an der Open Asset Import Library mit.
Benutzeravatar
Krishty
Establishment
Beiträge: 7929
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Linkdump

Beitrag von Krishty »

Genau, die Prüfung auf 0x1fffe00 ist sicher. Die hat aber GCC erzeugt – im Original stand die Prüfung an anderer Stelle, und prüfte auf 0…511. Und GCC erzeugte die Prüfung nun Mal in der Annahme, dass weiter oben kein Überlauf stattfinden darf.

Er gibt ja ein Beispiel für eine Zahl, die überläuft. Kannst ja mal durchrechnen.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
udok
Beiträge: 32
Registriert: 01.02.2022, 17:34

Re: Linkdump

Beitrag von udok »

Immer mit -fwrapv compilieren!
Die gcc Entwickler entwickeln leider für ihre abstrakte Maschine, und nicht mehr für die Softwarepraxis.
Der nächste C/C++ Standard schafft diese Auswüchse zum Glück ab.
Benutzeravatar
Krishty
Establishment
Beiträge: 7929
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Linkdump

Beitrag von Krishty »

udok hat geschrieben: 28.11.2022, 22:36Die gcc Entwickler entwickeln leider für ihre abstrakte Maschine, und nicht mehr für die Softwarepraxis.
Du sagst das, als wäre das was Negatives.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
udok
Beiträge: 32
Registriert: 01.02.2022, 17:34

Re: Linkdump

Beitrag von udok »

Man macht damit guten getesteten Code kaputt, und das ist meiner Meinung nach schlecht.
Und dazu völlig unnötig. Diese Optimierung bringt in der Praxis ja nichts.
Wenn man eine Option -fenable-wrapv-optimization eingebaut hätte, dann wäre das auch ok.
C war schon immer sehr "locker" standardisiert, in dem Glauben dass die oberen 10% der Entwickler
(die Compilerentwickler unter anderem) wissen was für die Plattform sinnvoll ist und was eher nicht.
Und bei solchen Dingen steigen 90% der Entwickler nicht mehr durch.
Alexander Kornrumpf
Moderator
Beiträge: 1976
Registriert: 25.02.2009, 13:37

Re: Linkdump

Beitrag von Alexander Kornrumpf »

Krishty hat geschrieben: 28.11.2022, 22:55
udok hat geschrieben: 28.11.2022, 22:36Die gcc Entwickler entwickeln leider für ihre abstrakte Maschine, und nicht mehr für die Softwarepraxis.
Du sagst das, als wäre das was Negatives.
In Ergänzung zu https://zfx.info/viewtopic.php?p=69984#p69984

Ich will mich hier nicht zu sehr einmischen, weil mir mit jedem Tag im Forum (und, ironischer Weise, jedem CppCon Talk auf youtube) klarer wird, dass ich eher nie in meinem Leben für Geld C++ schreiben will, in anderen Worten, das ist euer Krieg ...

aber

... ich habe eine erstaunlich starke Meinung zu dem Thema:

In welchem Universum ist die Idee nicht vollkommen weltfremd, dass es gleichwertig sei,

(a) programmweit beliebigen Code zu emittieren, der klar der intendierten Semantik dessen, was der Programmierer hingeschrieben hat,
widerspricht
oder
(b) einen integer überlaufen zu lassen

weil der Standard ja beides gleichermaßen als UB erlaubt?

Ich verstehe warum GCC das tut und ich verstehe vor allem auch warum GCC das _darf_ (falls jemand zu einer Belehrung ausholen wollte) aber wir sind uns wohl hoffentlich einig, dass das ein praxisrelevanter trade-off zwischen Performance und Benutzbarkeit ist, der die Sprache zwangsläufig in eine Niesche drängt (nach meinem Verständnis entgegen des erklärten Ziels der C++ Community).

Eine Sprache zu deren sachgemäßen Verwendung man derart arkane willkürliche Regeln verinnerlicht haben muss, müsste eigentlich wegen praktischer Unbenutzbarkeit verschrien sein, und gewissermaßen sind C und C++ außerhalb ihrer eigenen Communities ja auch genau das. Aber diese Regeln gemeistert zu haben bedient halt eine Art von Elitismus, den eine bestimmte Art von Programmierern sehr liebt. Ich möchte behaupten, das ist nicht die Art von Programmierer, die man seine Toolchain bauen lässt, aber was weiß ich schon.

Wenn man heute, im Sinne des Eingangszitats, nochmal eine Maschine abstrahieren würde, um dagegen Code zu emittieren, scheint es mir extrem unwahrscheinlich, dass man genau diejenigen Abstraktionen nochmal wählen würde, die es in den 80ern erlaubt haben, überhaupt in endlicher Zeit zu kompilieren. Die Idee, dass die Regeln für UB irgendeine tiefere Wahrheit des Universums kodifizieren und nicht einfach nur ein zufälliges Artefakt von pragmatischen, aber ihren Gründen nach weitestgehend überholten Entscheidungen sind, ist von außen betrachtet extrem befremdlich.

Ich hatte dot hier https://zfx.info/viewtopic.php?p=70058#p70058 nicht kommentiert, weil ich gerade keine keine Diskussion in einem Bereich vom Zaun brechen wollte, den er sehr viel besser versteht, als ich es tue, aber ich denke ehrlich gesagt nicht, dass das Argument, das er da macht (lest selbst) zieht.

Im Falle eines integer overflow ist es ja eben gerade nicht so, dass der Compiler überhaupt gar nicht mit "zero overhead" wissen kann, was er tun soll oder auch nicht tun soll. Es gibt, nach meinem begrenzten Verständnis, sehr wohl eine zero overhead Möglichkeit lokal mit dem Fehler umzugehen und das ist halt den integer überlaufen (=wrappen) zu lassen. Soviel ich weiß haben Implementierungen über Jahrzehnte genau das gemacht (was theoretisch sehr gut definiertes Verhalten ist) und niemand ist an dem "overhead" gestorben.

Vielleicht verstehe ich aber auch einfach nicht richtig was ein integer overflow ist? Es ist, zum Vergleich, erstaunlich schwer, "sicher" rauszufinden, was die vollständig definierte JVM bei Overflow macht, weil die Spezifikation anscheinend nur sagt, dass ein Overflow nicht behandelt wird, und man muss quasi schon wissen, dass das in der Praxis bedeutet, dass die Werte wrappen. Ich habe mein Leben in der naiven Annahme verbracht, dass das halt das ist was die CPU tut, wenn man gar nichts weiter tut, aber vielleicht ist das ein x86 quirk, den die JVM auf alle Plattformen ausweitet?

Das Meta-Problem hier ist jedenfalls schon allein daran offensichtlich, dass alle paar Jahre wieder jemand neu für sich entdeckt, dass GCC das macht, und damit "trended". Fefe reklamiert z. B. für sich einer der ersten gewesen zu sein, die auf den Radar gebracht haben, dass das ein Security Problem sein könnte (das ist vermutlich der Linux-Kernel-Bug, den dot in seinem Beitrag nennt) und unabhängig davon, ob es stimmt, dass fefe das "entdeckt" hat, ist das eher so 10 Jahre her.
Benutzeravatar
Schrompf
Moderator
Beiträge: 4552
Registriert: 25.02.2009, 23:44
Benutzertext: Lernt nur selten dazu
Echter Name: Thomas Ziegenhagen
Wohnort: Dresden
Kontaktdaten:

Re: Linkdump

Beitrag von Schrompf »

Alexander Kornrumpf hat geschrieben: 29.11.2022, 01:07 Ich verstehe warum GCC das tut und ich verstehe vor allem auch warum GCC das _darf_ (falls jemand zu einer Belehrung ausholen wollte) aber wir sind uns wohl hoffentlich einig, dass das ein praxisrelevanter trade-off zwischen Performance und Benutzbarkeit ist, der die Sprache zwangsläufig in eine Niesche drängt (nach meinem Verständnis entgegen des erklärten Ziels der C++ Community).

Eine Sprache zu deren sachgemäßen Verwendung man derart arkane willkürliche Regeln verinnerlicht haben muss, müsste eigentlich wegen praktischer Unbenutzbarkeit verschrien sein, und gewissermaßen sind C und C++ außerhalb ihrer eigenen Communities ja auch genau das. Aber diese Regeln gemeistert zu haben bedient halt eine Art von Elitismus, den eine bestimmte Art von Programmierern sehr liebt. Ich möchte behaupten, das ist nicht die Art von Programmierer, die man seine Toolchain bauen lässt, aber was weiß ich schon.
Exakt mein Problem, und eine der Quellen für meine Verachtung für die GCC-Entwickler. Die andere war deren "wir wollen nicht als Lib benutzt werden und obfuscaten"-Attitüde. Aus beiden spricht meines Erachtens ein bestürzendes Missverständnis der eigenen Rolle im menschlichen Universum. Und ich bin ja nicht der Einzige, der darin den Grund für den Aufstieg von Clang sieht.
Häuptling von Dreamworlds. Baut an was Neuem. Hilft nebenbei nur höchst selten an der Open Asset Import Library mit.
udok
Beiträge: 32
Registriert: 01.02.2022, 17:34

Re: Linkdump

Beitrag von udok »

Es gab auch Architekturen, die kein 2-er Kompliment verwendeten.
Viele Digitale Signalprozessoren haben Sättigungsarithmethik - da gibt es keinen Überlauf.
Irgendwann gab es auch CPUs mit Betrag und Vorzeichenbit (erste Cray?).
Es gibt aber keine CPU, die das Überlaufverhalten hat, das der Gnu Compiler vorraussetzt.
Daher hat der C-Standard nicht vorgeschrieben, was passiert wenn ein integer überläuft.
Interessanterweise, schreibt der C-Standard aber für UNSIGNED integer 2-er Kompliment vor.
In der Praxis tritt Überlauf in vielen Fällen gewollt oder ungewollt auf (Bitshift, Multiplikation...),
und das Verhalten muss für den Entwickler nachvollziehbar definiert sein.
Die bisherige Praxis war einfach das zu machen was die Hardware macht (2-er Kompliment am PC).
Es gibt sicher noch etliche andere Punkte, wo der gelebte Standard nicht offiziell abgesegnet ist.
Das ist auch bewusst so gewollt, um effiziente Implementierungen zu ermöglichen.
Wenn der neue C Standard 2-er Kompliment für alle Integer vorschreibt, dann gibt es aber
für Digitale Signalprozessoren keinen standardkonformen C-Compiler mehr?
Der Aufstieg von clang hatte auch viel mit der weniger restriktiven Lizenz zu tun,
die es Google/Apple einfacher machten da zu investieren.
Benutzeravatar
Krishty
Establishment
Beiträge: 7929
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Linkdump

Beitrag von Krishty »

Alexander Kornrumpf hat geschrieben: 29.11.2022, 01:07Eine Sprache zu deren sachgemäßen Verwendung man derart arkane willkürliche Regeln verinnerlicht haben muss,
Fun fact: Diese Regeln musst du in jeder Sprache verinnerlichen. Dass du für Java erstmal nachschlagen musstest, was bei Überlauf passiert, ist ja das beste Beispiel. Siehe auch udoks Hinweise aus dem DSP-Bereich. Ob die Zahl bei Überlauf sättigt, wiederholt, eine Ausnahme schmeißt (auch das erscheint ja einigen Programmierern natürlich) ist ja Geschmackssache. In jedem Fall hat der Programmierer das Verhalten mit an Sicherheit grenzender Wahrscheinlichkeit nicht bedacht, und mit gefühlter fifty-fifty-Chance einen Bug.

Befremdlich an C/C++ ist eher, dass dabei eine ganz andere Stelle des Programms kaputtgehen kann.

Für mehr UB-Apologismus empfehle ich auch https://people.eecs.berkeley.edu/~wkahan/JAVAhurt.pdf
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Alexander Kornrumpf
Moderator
Beiträge: 1976
Registriert: 25.02.2009, 13:37

Re: Linkdump

Beitrag von Alexander Kornrumpf »

Krishty hat geschrieben: 29.11.2022, 11:20
Alexander Kornrumpf hat geschrieben: 29.11.2022, 01:07Eine Sprache zu deren sachgemäßen Verwendung man derart arkane willkürliche Regeln verinnerlicht haben muss,
Fun fact: Diese Regeln musst du in jeder Sprache verinnerlichen. Dass du für Java erstmal nachschlagen musstest, was bei Überlauf passiert, ist ja das beste Beispiel.

[...]

Befremdlich an C/C++ ist eher, dass dabei eine ganz andere Stelle des Programms kaputtgehen kann.
Ich glaube das ist ein Missverständnis. Ich "weiß" was in Java bei Überlauf passiert. Es ist nur schwer rauszufinden wie "sicher" ich mir dessen "wirklich" sein darf, gerade _weil_ Leute die online über Java schreiben gar nicht die Denke verinnerlicht haben, dass das überhaupt eine Frage sein könnte. Ich denke die Behauptung, dass man einigermaßen erfolgreich Java programmieren kann, ohne je über solche Fragen nachzudenken wird dadurch eher gestützt als widerlegt.

Um das auch nochmal zu betonen, es geht mir keinesfalls darum welches von {C++, Java} besser ist, aus dem Alter sind wir hoffentlich raus.

Der Kern ist in dem zweiten zitierten Satz. Natürlich muss man in jeder Sprache "die Regeln" kennen, aber quasi jede andere Regel hat weniger Entropie als "alles kann überall passieren" und "die Regeln" können näher dran oder weiter weg von der Intuition "der meisten" Menschen sein.

Der Grund dass das überhaupt immer wieder Diskussionspunkt ist, ist ja gerade dass GCCs Auslegung der Regeln der Intuition vieler Menschen widerspricht. Die Story, die du verlinkst ist bezeichnenderweise ja nicht "Schaut her, diese coole Sache macht GCC", sondern "ich konnte mir das Verhalten meines eigenen Programms nicht erklären und selbst als ich es dann isoliert hatte und eine Theorie gebildet hatte was passiert habe ich trotzdem mal lieber beim Compiler Team nachgefragt ob es auch wirklich kein Bug ist". Das ist nicht die "User Experience" der meisten anderen Sprachen.
Siehe auch udoks Hinweise aus dem DSP-Bereich. Ob die Zahl bei Überlauf sättigt, wiederholt, eine Ausnahme schmeißt (auch das erscheint ja einigen Programmierern natürlich) ist ja Geschmackssache. In jedem Fall hat der Programmierer das Verhalten mit an Sicherheit grenzender Wahrscheinlichkeit nicht bedacht, und mit gefühlter fifty-fifty-Chance einen Bug.
Wie gesagt, ich verstehe sehr wohl, soweit man das eben von außen kann, wieso C++ ist wie es ist. Das ist nicht der Punkt. Der Punkt ist dass diese Entscheidung des GCC Teams sich mit dem (vielleicht durch mich missverstandenen) Claim der C++ Community widerspricht, eine moderne general purpose Sprache sein zu wollen.
Benutzeravatar
xq
Establishment
Beiträge: 1562
Registriert: 07.10.2012, 14:56
Alter Benutzername: MasterQ32
Echter Name: Felix Queißner
Wohnort: Stuttgart & Region
Kontaktdaten:

Re: Linkdump

Beitrag von xq »

Das Gute ist ja, dass neuere Sprachen diese Thematik addressieren. Zig hat zum Beispiel die Operatoren + (UB bei Überlauf in unsafe modes, Panic in safe modes), +% (Immer wraparound nach Zweierkomplement) und +| (immer saturierende Arithmetik), und wenn einem das nicht reicht, gibt es noch @addWithOverflow(), welches dann halt "ergebnis + overflow-bit" ausgibt

Rust hat ebenfalls overflowing_add, wrapping_add, carrying_add, checked_add, saturating_add, unchecked_add sowie den operator +, welcher in debug modes panic on overflow hat, und in release modes wrapped.

Die Rust-Semantik von + ist imho komplett bescheuert, weil sie kein wirklich vorhersehbares Verhalten erzeugt, und ungewollte Overflows zu Laufzeit schön leise verschluckt und plötzlich fährt man rückwärts statt schneller.

Und auch sonst wird UB besser behandelt als in C. Das Interessante ist, dass Zig in ReleaseFast potentiell schnelleren Code generiert als äquivalentes C, da in Zig ein Overflow bei regulärem + UB ist, und der Compiler damit besser optimieren kann, was sehr praktisch ist, wenn einem die Performance wichtig ist. Wenn man aber sagt, dass einem Sicherheit wichtiger ist, kann man mit ReleaseSafe compilieren, wo der Overflow garantiert in einer Panic endet.
War mal MasterQ32, findet den Namen aber mittlerweile ziemlich albern…

Programmiert viel in ⚡️Zig⚡️ und nervt Leute damit.
Antworten