Bis auf das Unicodeproblem, was aber zufällig keinen Bufferoverflow erzeugt, sondern eher einen Bufferunderflow, sah ich eine direkten "schwerwiegenden" Fehler.
OK, abgesehn von einer Funktion (WinExex), welche seit 23 Jahren als "nicht verwenden, nur für Abwärtskompatibilität von uraltem Code" gekennzeichnet ist.
In ExecuteConsole wird ab D2009 halt
ANSI in einem
Unicode-CharArray gespeichert wird, was so kaum stört, aber OemToChar wird meckern, vonwegen potentiellem Datenverlust, weil es ja einen PAnsiChar haben will, aber einen PChar/PWideChar bekommt. (der Compiler weiß nunmal nicht, dass dort wirklich nur
ANSI drin ist, durch den vorherigen Fehler beim Befüllen).
Zitat:
Für delphi 7 taugt der code, hat mich noch nie im stich gelassen.
Problem ist halt, dass schon seit 9 Jahren Delphi standardmäßig mit
Unicode arbeitet, was in der EDV gefühlt einem halben Jahrhundert entspricht.
Vorallem Codes, welche Andere verwenden sollen, wären gut beraten, wenn sie mit halbwegs aktuellen Delphiversionen zusammen arbeiten.
Tipp zum Testen:
https://www.embarcadero.com/de/products/delphi/starter
PS: Wäre vor Jahrzehnten schon AnsiChar statt Char dort verwendet worden, wo explizit
ANSI genutzt wird, dann hätte es dieses Problem nicht gegeben.
Sowas war eines der größten Gründe, welche bei Einführung von Delphi 2009 in vielen AltCodes zu Problemen führte.
> immer die "richtigen" Typen verwenden und schon minimieren sich die potentiellen Fehlerstellen.