head_01 head_02 head_03 head_04 head_05 head_06 head_07

 
Sehenswert
Audiophiler Musikgenuss
Bilderalben
Andere Webseiten
Ansteckend
Nürburgring Nordschleife
Verblassend
Veranstaltungen
Erinnerungen
Bilder
Kommunikativ
Gästebuch
Email-Formular
Facebook
Zugehörig
Mein Xing
Mein Facebook
.

Fefes Blog

Stand: 23.06.2017 08:24:59

D soll Teil von gcc werden. D ist eine Programmiersprache, die sich als Konkurrent zu C++ sieht, und als Nachfolger von C. Die Featureliste klingt auch erst mal nicht schlecht, aber es hat mich persönlich nicht überzeugen können. C++ hat sich ja als Design-Richtlinie entschieden, nur Abstraktionen in der Sprache zu machen, die "nichts kosten", und in der Library im Standard vorzugeben, welche asymptotische Laufzeit die Algorithmen haben sollen. So kann man sich als Programmierer im Wesentlichen darauf verlassen, dass die Laufzeit vorhersagbar und deterministisch bleibt. Überraschungen gibt es jedenfalls nur selbstverschuldete :-)Bei D ist genau das über Bord geworfen worden. Das Ziel war anscheinend, ein C++ zu kriegen, das sich mehr wie eine Skriptsprache anfühlt. Problem: An der Stelle kann D nicht mit Go mithalten. Und C++-Programmierer gewinnt es mit dem Ansatz auch nicht viele. So hat D Garbage Collection, aber ohne die fanatischen Optimierungen des Go-Teams. D hat dynamische Strings und assoziative arrays, aber als Feature der Sprache, nicht des Runtimes. D nimmt die schlechten Ideen von C++ mit (Template Metaprogramming, Operator Overloading) aber nicht die Vorteile (deterministisches Laufzeitverhalten, zero-cost abstractions). Ich hacke auf dem deterministischen Laufzeitverhalten so rum, weil das der Grund ist, wieso heute immer noch viele Realtime-Geschichten in C gemacht werden. Mit striktem Regelkorsett oben drüber, wie "keine Rekursionen" und so. Die Lösung von D? Sie behaupten einfach, man könne in D auch systemnah programmieren. Behaupten reicht nicht, liebe D-Leute. Ich will D nicht schlechter machen als es ist. D hat auch gute Ideen. Design by Contract zum Beispiel, das "synchronized"-Keyword, ? ist nicht alles schlecht. Und vielleicht wird D-Code ja mit dem Backend von gcc sogar schneller als Go-Code. Auf der anderen Seite hat auch Go ein gcc-Backend. Ich glaube, D ist von Go getötet worden, und gcc macht hier einen Fehler. gcc schleppt schon jetzt mehrere Frontends mit sich herum, die dann nicht ordentlich mitgepflegt werden. java, go, ada, und jetzt dann auch noch D. Und die Probleme im C-Teil bleiben dann liegen (beispielsweise das fehlende Stack Probing, das ich die Tage ansprach). Update: Ich sollte das vielleicht knackiger formulieren. Die Vorteile, die D über C++ hat, rechtfertigen dem Umstieg nicht, weil man das zum Großteil auch in C++ haben kann, und dann verliert man nicht seine reingesteckte Erfahrung und den Zugriff auf die ganzen existierenden Libraries. Leute ohne C++-Ballast würden eh lieber gleich zu Go greifen. Und Leute, die die sichere Programmierung haben wollen, mit der D Werbung macht, können das bei Rust haben, ohne die undeterministischen Laufzeiten oder Abstraktionskosten schlucken zu müssen.

Die Religionsbehörden aus der Türkei und Ägypten haben sich ernstlich von der "liberalen Berliner Moschee" trollen lassen und geben Statements von sich, da denkt man erstmal an den Postillon. Die Türkei finden, es sei ja wohl völlig offensichtlich, dass das eine fiese Sabotage-Aktion der Gülen-Bewegung gegen den Islam sein (lolwut!? ), und zwar so offensichtlich, dass sie nicht finden, irgendwelche Belege vorweisen zu müssen (sowohl die Moschee-Gründerin als auch die Gülen-Bewegung bestreiten das übrigens). Was macht diese Moschee eigentlich so liberal? Nun? In der Ibn-Rushd-Goethe-Moschee beten Frauen und Männer nebeneinander. Das Gotteshaus steht Sunniten, Schiiten und Aleviten offen. Das erste Freitagsgebet leiteten ein Mann und eine Frau gemeinsam. Die Imamin trug kein Kopftuch. SODOM UND GOMORRHA! Aber wartet mal, hier ist der Beitrag der Fatwa-Behörde aus Ägypten:"Die Behauptung, dass das Tragen des Kopftuchs Frauen diskriminiere, ist falsch. Denn Frauen müssen sich ebenso wie Männer an das islamische Recht halten. Das Bedecken bestimmter Körperteile beim Gebet ist für Musliminnen ebenso Pflicht wie für Muslime, auch wenn es bei Frauen andere Körperteile sind als bei Männern. Bei Verletzung dieser Vorschrift wird das Gebet ungültig. "Bitte was? Das Gebet wird ungültig? Das klingt ja wie Formularausfüllen im Behördenverhältnis! Nein, mein Herr, das Gebet war ungültig, hier lag ein klarer Formfehler vor! Aber das Highlight ist das hier:Auch findet die Religionsbehörde nicht, dass Terrorismus und Extremismus durch Bemühungen wie die neue liberale Moschee bekämpft werden könnten: "Im Gegenteil: Die Missachtung der Grundregeln einer Religion ist ebenfalls Extremismus. Es handelt sich um einen Angriff auf die Religion. "Gut, dass wir das mal geklärt haben!

Nachschlag zu dem Stack Probing: Die grsecurity-Leute haben einen länglichen, schwer erträglichen Rant dazu geschrieben, weil sie sich wie immer von allen anderen unterrespektiert fühlen. Aber technisch haben sie, ebenfalls wie immer, mal wieder völlig Recht. Ein Einsender kommentiert außerdem:Vielleicht wäre es noch gut zu erwähnen, das neben GCC auch clang nicht wirklich Unterstützung für Stack Probes hat? außer man benutzt es unter Windows, weil da Stack Probes anscheinend Teil der ABI sind. Siehe auch dieser schöne Rant. Im Zusammenhang mit Rust gabs da in den letzten Tagen etwas Aufregung (Memory safe? Aber ihr habt doch unkontrollierte Stack Overflows! ) und einer der Rust Entwickler hat einen Patch für clang gemacht (bzw. einen alten den niemand updaten wollte hoffentlich mergebar gemacht)Mit etwas Glück ist das dann wohl zumindest in naher Zukunft mit clang kein Problem mehr. Das wäre schön!

Benutzt hier jemand Software, die RAR-Archive auspacken kann? Given the wide prevalence of the unrar source code in third-party software, quite a few downstream parties will be affected. The source code with the fixes can be found under http://www. rarlab. com/rar/unrarsrc-5. 5. 5. tar. gz - downstream parties are encouraged to quickly update and ship fixes. Oh gut, das betrifft bestimmt so gut wie niemanden! 1!! Ja gut, ausgenommen 7-zip und so, und natürlich die ganzen Antiviren. Dort war der Bug übrigens zum ersten Mal aufgefallen. It appears that the VMSF_DELTA memory corruption that was reported to Sophos AV in 2012 (and fixed there) was actually inherited from upstream unrar. For unknown reasons the information did not reach upstream rar or was otherwise lost, and the bug seems to have persisted there to this day. Ja warum würde man auch upstream Bescheid sagen! Da hat man ja einen wettbewerblichen Nachteil von als Schlangenöl, wenn die anderen Schlangenöler informiert werden, und wenn die Software insgesamt sicherer wird! 1!!

Gerade geht ein schönes Paper rum, wie man eine Kollision zwischen Heap und Stack ausnutzen kann. Dass das ein Problem ist, war schon immer klar. Der Heap wächst nach oben, der Stack nach unten, was wenn die sich treffen? Das Problem ist so alt, dass früher die "Lösung" einfach war, zu sagen, naja, dann ist Speicher alle, und wenn Speicher alle ist, dann crashen die Programme ja auch ohne Kollision! 1!! Die besseren Programme haben dann irgendwann angefangen, Speicherknappheit zu erkennen und nicht zu crashen, und so gab es auch irgendwann eine halbherzige "Lösung" für das Kollisionsproblem? eine "Guard Page". Speicherschutz funktioniert über eine Hardware-Komponente namens MMU, Memory Management Unit, und die arbeitet nicht auf Bytes sondern auf Pages. Pages sind im Allgemeinen 4KiB groß. Wenn man auf eine Page zugreift, die nicht da ist, dann wirft der Prozessor eine Exception, die das Betriebssystem abfangen kann. So wird beispielsweise Swapping implementiert. Aber wenn der Zugriff auf eine Page war, die nicht da sein sollte, dann kriegt das laufende Programm einen Segmentation Violation signalisiert (theoretisch auch abfangbar, aber üblicherweise nicht abgefangen und prinzipiell auch keine so gute Idee) und crasht. Die Idee der Guard Page ist, dass man zwischen dem Ende des Heaps und dem Anfang des Stacks eine Page leer und ungemappt lässt. Das klingt erstmal gut, ist es aber nicht. Denn auf dem Stack kann man auch lokale Variablen deklarieren, die größer als eine Page sind, und so die Guard Page überspringen. Nichts hiervon ist irgendwie überraschend oder eine neue Erkenntnis. Und die Lösung ist auch offensichtlich. Wenn der Compiler auf dem Stack etwas größer als eine Page alloziert, dann emittiert er eben auch Code, der alle Pages auf dem Weg einmal kurz anfasst. Visual Studio tut das seit über 10 Jahren, wahrscheinlich schon viel länger. Seit ich mir das erste Mal deren Disassemblat angeguckt habe, tut es das. gcc tut es aber nicht. Ich erinnere mich noch, mich 2005/2006 mit meinem Kumpel Ilja über genau dieses Problem unterhalten zu haben, und ich bin mir fast sicher, dass er den gcc-Leuten gesagt hat, sie sollen da mal solchen Code emittieren. Aber er findet gerade kein verlinkbares Material. Dafür, dass gcc da seit 20 Jahren auf einem bekannten Problem sitzt, lege ich aber meine Hand ins Feuer. das war komplett vermeidbar, und die, die es hätten vermeiden müssen, haben es nicht getan. Ohne eine Ausrede dafür zu haben. Hier ist z. B. ein Beitrag von 2013, der das Problem beschreibt. Krasserweise gibt es sogar grundsätzlich Support für Stack Probing in gcc, der ist nur bei C und C++ nicht angeschaltet. Hier ist ein Bug von 2007 dazu. Ich bin mir aber sicher, dass das Problem schon länger bekannt ist.
.
.

Aktuelle Nachrichten

Stand: 23.06.2017 08:24:59
.
.

Heise IT News

Stand: 23.06.2017 08:24:59
.
.

Honda World News

Stand: 23.06.2017 08:24:59
.
.

Formel 1 News

Stand: 23.06.2017 08:24:59
.