Hallo Assertor!
Das ist ja schonmal gut zu wissen, dass man das ganze mit dem nativen Code umschiffen kann. Ich verstehe aber wirklich nicht, wie der vom Delphi Compiler generierte Code - selbst wenn von Delphi Code aufgerufen - andere Ergebnisse bringt, nur weil ein anderer Linker das ganze zusammenpackt. Oder halt die CodeGear Panscher haben mal wieder einen Bug nur einseitig gefixt (sprich:
DCU Erstellung klappt, OBJ Erstellung nicht). Ich habe sowas von die Nase voll mit den ganzen Streitereien mit CodeGear. Um deren Fehler nicht mehr zu haben zwingen sie einen immer wieder ständig neues Geld für neue Versionen auszugeben und legen alles erst auf eine Klage bezüglich Gewährleistungsansprüchen bei Software an. Es ist mehr als traurig - und zu guter Letzt wurden noch die Update Preise verdoppelt. Na herrlich...
Aber egal, darum geht es hier nicht. Vielen Dank schonmal für deine Erkenntnisse. Ich hatte zuvor noch keine Kenntnisse über die neue DEV v5.2, habe sie mir aber gerade mal geladen und were somit auch unseren
DEC Stand mal updaten auf 5.2.
Ansonsten wäre vllt. ein Blick auf meinen weiteren Beitrag bezüglich der in der
DEC enthaltenen LHSS Komprimierung (
DEC: LHSS Komprimierung: Rückgabewerte unbrauchbar).
Nachtrag: wo ich gerade den EIntOverflow sehe: Wir haben bei uns fest definierte Compilereinstellungen welche für alle Projekte verbindlich sind. Unter anderen auch der Overflow und Range Check. Dieser ist immer und überall an und stösst bei der
DEC in Bereich der Cipher sowie der LHSS Komprimierung mehrfach auf wenig Gegenliebe. Leider hat ein weiterer Bug im RAD2007 Studio den Effekt, dass Compilereinstellungen für den Delphi Compiler unter häufigen Umständen aus den Projektoptionen nicht dem Delphi Compiler übergeben werden im automatischen Build Prozess mit msbuild. Dadurch werden explizite Editierungen der
DEC Quellen nötig (leider wie nun schon für das $Z4, also 4 Byte Enum Size) - welche wir/ich eigentlich vermeiden wollten bzw. möglichst gering halten wollten. Von daher wäre eine globale Abschaltung in der
Ver.inc auch keine so gute Lösung, es wäre besser sie bei den Stellen abzuschalten innerhalb der Lib, wo gewollt mit Überläufen gerechnet wird. Somit ist zum einen sichergestellt: Ja, wissen um den Überlauf und der ist gewollt hier und gleichzeitig würde er an anderen Stellen aussteigen, wo dies definitiv nicht gewollt wäre. Das wäre mal eine wirklich gute Erweiterung der
DEC, falls du da nochmal eine
DEC 5.3 planst ^^.
Vielen Dank!
Grüsse,
Thomas