Vorstellung: au3Mythos - Statische Code- & Scoping-Analyse für AutoIt 3

Pustekuchen

Hallo zusammen,

ich möchte euch heute ein neues Open-Source-Projekt von mir vorstellen, das die statische Code- und Scoping-Analyse für AutoIt 3 ergänzt: au3Mythos.

Motivation & Hintergrund

Inspiriert von den aktuellen Diskussionen über statische Codeanalyse und Fehlererkennung in Software, habe ich mich gefragt, wie weit man die klassische statische und heuristische Analyse für AutoIt 3 treiben kann, um typische Laufzeit- und Gültigkeitsfehler bereits vor dem Ausführen des Codes zu finden.

Das Ergebnis ist au3Mythos – ein mächtiges Debug- und Analysewerkzeug, das sich an alle Entwickler richtet, die die Stabilität und Code-Hygiene ihrer AutoIt-Projekte pragmatisch erhöhen möchten.

Was ist au3Mythos?

au3Mythos ist ein statischer Code-Analysator und Compiler-Wrapper. Er lässt sich als Drop-in-Ersatz für die standardmäßige Au3Check.exe konfigurieren und integriert sich nahtlos in Editoren wie SciTE, ISN AutoIt Studio oder VS Code, wenn diese schon die originale au3check.exe unterstützen.

Sobald eine Syntaxprüfung gestartet wird (z. B. per Ctrl+F5 in SciTE), fängt der Wrapper den Aufruf ab. Über ein Regelwerk wird entschieden, ob der Code durch den erweiterten Scoping-Analyzer (mythos) läuft oder direkt an die originale Prüfung (original) übergeben wird.

[Blockierte Grafik: https://raw.githubusercontent.com/Blowcake/mytho…tab_routing.png]

Was wird zusätzlich geprüft?

Während der originale Au3Check hervorragende Arbeit bei der Syntaxvalidierung leistet, konzentriert sich au3Mythos zusätzlich bis in die Tiefe auf logische Scoping-Probleme und potenzielle Laufzeitfehler:

Variable Block-Scoping Bugs: Variablen, die innerhalb eines Kontrollblocks (If, For, Select) deklariert, aber außerhalb dieses Blocks referenziert werden.
Unsafe Return Dereferencing: Direktes Indizieren von Rückgabewerten von Funktionen (z. B. _MyFunc()[0]) ohne vorherige Prüfung (z. B. mit IsArray() oder @error).
@error- und @extended-Überschreibungen: Erkennung von Zuweisungen oder Funktionsaufrufen, die das @error-Register vor einer Prüfung überschreiben.
Array-Dimensionen: Plausibilitätsprüfungen bei statisch erkennbaren Array-Dimensionen und Index-Zugriffen.
Ungebrauchte Variablen & doppelte Deklarationen innerhalb verschachtelter Scopes.

Komponenten

Settings Manager GUI: Ein Win32-GUI, um Routing-Regeln, Profile und Warnstufen (-w 1 bis -w 7) zu verwalten. Der besondere Clou mit dieser flexiblen Konfigurationsmöglichkeit ist: Der Prüflauf kann mit selbst gewählten Parametern durchgeführt werden, egal welche Einstellungen das aufrufende Programm (wie SciTE) fest einprogrammiert hat – ohne dass man irgendwo eine Zeile Code oder Editor-Konfigurationen ändern muss.
Installer & Uninstaller: Integriert den Wrapper und sichert die originale Au3Check.exe als Au3Check_Original.exe. Bei der Deinstallation wird der Originalzustand rückstandslos wiederhergestellt.
Präzises Line-Mapping: Schon mal vor dem Problem gestanden, dass eine AutoIt-Fehlermeldung eine Zeilennummer der zusammengeführten/preprocessed Datei ausgibt und du keine Ahnung hast, welche Zeile in welcher deiner vielen Include-Quelldateien das eigentlich ist? au3Mythos übersetzt diese Zeilenangaben präzise zurück in die Original-Quelldatei und die dortige tatsächliche Zeilennummer.

GitHub & Open Source

Das Projekt ist Open Source unter der MIT-Lizenz:

GitHub-Repository: Blowcake/mythos-secure-static-and-code-analyzer (Wenn euch das Projekt gefällt, freue ich mich natürlich riesig über einen Stern ⭐ auf GitHub!)

Downloads & Changelog

Version 1.1.0 (Enthält vorkompilierte Standalone-Dateien – keine Python-Installation erforderlich!)
- Download compiled ZIP Package
- View Changelog / Release Notes

Hinweis: Dies ist ein unabhängiges Open-Source-Projekt und steht in keiner Verbindung zum offiziellen AutoIt-Entwicklerteam.

Da ich das Ganze bisher alleine im stillen Kämmerlein entwickelt und getestet habe, würde ich mich riesig über euer Feedback freuen! Jede Rückmeldung zu bisher nicht entdeckten Fehlern, Inkompatibilitäten oder Verbesserungsvorschlägen ist extrem willkommen. Ich unterstütze auch gerne jeden dabei, die mächtige JSON-Schnittstelle in eigene Projekte zu integrieren, um das Maximum an Unterstützung aus dem Tool herauszuholen.

Viele Grüße,

Harald Frank

**AspirinJunkie**

Ich hatte es ja auf github bereits angesprochen, dass ich mir natürlich au3mythos angesehen habe.
Wie bereits erwähnt, geht mein persönlicher Blick hierbei zuerst auf False-Positives, da mich diese schon bei Au3Check ziemlich stören.
Wobei: Eigentlich weniger die Meldungen selbst, als eher die Leute die dann meinen ich müsste meinen Code doch entsprechend dem vermeintlichen "Fehler" anpassen.

Ich habe daher einige Testfälle gebaut, welche auch entsprechend anschlagen. Das ist im ersten Aufschlag auch schlicht normal, dass noch einige Dinge aufploppen. Hier mal mein Testscript dazu:

AutoIt

; Fall A: bedingtes "declare-once"-Global wird nicht als Deklaration erkannt
If Not IsDeclared("myGlobal") Then Global $myGlobal = 42

Func FallA()
	Return $myGlobal + 1   ; <-- au3Mythos: "Undeclared Variable"
EndFunc


; Fall B: case-insensitive case ;-)
Func FallB($cChar)
	Switch $cChar
		Case "j", "J"   ; <-- au3Mythos: "Duplicate Case Value" (Gross-/Kleinschreibung)
			Return "Buchstabe J"
	EndSwitch
	Return "anderes Zeichen"
EndFunc
; Hinweis: unnoetig gross/klein zu schreiben, da Switch case-insensitive prueft, aber falsch ist es dennoch nicht.
; Achtung: triggert nur in Funktionen - in Top-Level-Switches meldet der Check gar nichts (sollte ebenso untersucht werden).


; Fall C: StringRegExp ohne 3. Parameter liefert 0/1, kein Array
Func FallC($sName)
	Local $bIsTest = StringRegExp($sName, "(?i)Test")
	If $bIsTest Then   ; <-- au3Mythos: "Array Used as Boolean" (falsch, $bIsTest ist 0/1)
		Return "Test enthalten"
	EndIf
	Return "kein Test"
EndFunc


; Fall D: Lesezugriff in ElseIf-Bedingung wird uebersehen
Func FallD($fWert)
	Local $fSchwelleHoch = 0.8
	Local $fSchwelleNiedrig = 0.3   ; <-- au3Mythos: "Dead Store" + "declared, but not used" (2x), obwohl unten gelesen

	If $fWert > $fSchwelleHoch Then
		Return "hoch"
	ElseIf $fWert > $fSchwelleNiedrig Then   ; Lesezugriff hier wird uebersehen
		Return "mittel"
	Else
		Return "niedrig"
	EndIf
EndFunc


; Fall E: Lesezugriff in Case-Klausel wird uebersehen
Func FallE($iEvent)
	Local Const $EVENT_CLOSE = -3   ; <-- au3Mythos: "Unused Variable" + "Dead Store" (2x), obwohl unten gelesen

	Switch $iEvent
		Case $EVENT_CLOSE   ; Lesezugriff hier wird uebersehen
			Return "Schliessen"
		Case Else
			Return "Unbekannt"
	EndSwitch
EndFunc


; Fall F: Dim auf bereits deklarierte Variable (hier: ByRef-Parameter) ist nur Redimensionierung
Func FallF(ByRef $iVariable)
	Dim $iVariable[3] = [1, 2, 3]   ; <-- au3Mythos: "Deprecated Dim Use" (falsch, keine Neudeklaration)

	Return $iVariable[0]
EndFunc
; Erklaerung: Dim auf eine bereits deklarierte Variable ist reine Redimensionierung, keine Deklaration.
; Das wird teilweise gebraucht, um Variablen, die vorher nicht sicher ein Array sind, als solches zu dimensionieren.


; Fall G: Zuweisung an ByRef-Parameter ist nie "dead" - der Wert geht an den Aufrufer
Func FallG(ByRef $iErgebnis)
	$iErgebnis = 42   ; <-- au3Mythos: "Dead Store" (falsch, ByRef fliesst an den Aufrufer zurueck)
EndFunc


; Fall H: einzeiliges "If ... Then Local" wird nicht als Deklaration erkannt
Func FallH($bAktiv)
	If $bAktiv Then Local $sWert = "gesetzt"   ; <-- au3Mythos: "Undeclared Variable" - sogar auf der Deklarationszeile selbst
	If Not $bAktiv Then Return ""
	Return $sWert   ; <-- au3Mythos: "Undeclared Variable" (2. Meldung)
EndFunc
; Gleiche Wurzel wie Fall A, nur mit Local statt Global; mehrzeilige If-Bloecke loesen stattdessen Fall G aus.


; Fall I: Lesezugriff in Until-Bedingung wird uebersehen
Func FallI()
	Local $iMax = 3   ; <-- au3Mythos: "Dead Store" + "declared, but not used" (2x), obwohl in Until gelesen
	Local $iCount = 0

	Do
		$iCount += 1
	Until $iCount >= $iMax   ; Lesezugriff hier wird uebersehen
	Return $iCount
EndFunc
; Kurios: Lesezugriffe in While-, For- und Ternary-Ausdruecken werden korrekt erfasst - nur Until nicht.


; Fall J: Lesezugriff in einem Case-Bereich (To) wird uebersehen
Func FallJ($iWert)
	Local Const $BEREICH_MAX = 10   ; <-- au3Mythos: "Unused Variable" + "Dead Store" (2x), obwohl unten gelesen

	Switch $iWert
		Case 1 To $BEREICH_MAX   ; Lesezugriff im Bereichsausdruck wird uebersehen (wie Fall E)
			Return "im Bereich"
		Case Else
			Return "ausserhalb"
	EndSwitch
EndFunc

Alles anzeigen

Wenn man die kompletten Checks (also -d -w 1 -w 2 -w 3 -w 4 -w 5 -w 6 -w 7 --enable-experimental-checks) fährt, dann werden die im Code erwähnten False Positives gefunden.
Au3Check meldet hierbei übrigens das (korrekterweise) alles clean ist. Wenn man mit den Standardoptionen checkt, bleiben die Fälle A und H erhalten.

Darüber hinaus gibt es noch Probleme die sich aus dem jeweiligen Encoding der Datei ergeben. Dazu habe ich mal ein separates Skript in den Anhang gelegt.

So: Wie nun damit umgehen? Was ist der Zweck von statischen Code-Analyzern? Sie sollen frühzeitig, noch vor der Ausführung, auf mögliche(!) Problemstellen hinweisen. Diese schaut man sich dann an und kann entscheiden, wie man damit umgehen möchte. Egal wie ausgefuchst diese designt werden - sie werden niemals das komplette Laufzeitverhalten sauber vorhersagen können.

Ich plädiere daher einmal mehr dafür, die Ergebnisse von derartigen Tools eben nur als das zu betrachten was sie wirklich sind: lediglich Hinweise.
Auf keinen Fall sollten sie als Checkliste betrachtet werden, die bescheinigen, dass ein Skript erst dann sauber und korrekt ist, wenn diese nichts mehr finden.
Sprich: Auch wenn Au3Check und Verwandte meckern, sagt das noch nichts darüber aus ob ein Code sauber ist oder eben nicht.

Wenn man dies im Hinterkopf behält, ist gleichzeitig der Druck raus, die oben gefundenen False Positives noch mit in au3mythos zu beseitigen. Es wird darüber hinaus einfach noch weitere Fälle geben die dennoch fälschlich anschlagen. Ist halt prinzipbedingt so und irgendwann wird es dann auch mal zu komplex. Von daher wäre das pragmatischste auf den Hinweischarakter und die Prüfungspflicht des Anwenders zu verweisen. Dann ist das durchaus ein hilfeiches Tool (bekommst du es evtl. noch etwas fixer hin?) um Dinge aufzudecken, welche sonst untergehen würden.

Pustekuchen

Hallo,

erstmal vielen lieben Dank, du bist der erste von dem ich dazu Rückmeldungen bekomme, dazu noch mit guten und praxisnahen Beispielen.

Jeder Feedback den ich bekomme, ist für mich wertvoll und meistens nach einigem darüber grübeln, sehr lehrreich .o)

Mag komisch klingen, aber ich habe auf solche "Mängel" Rückmeldungen gehofft, die mich weiter in die richtige Richtung schubbsen.

Druck ist da keiner dahinter außer mein eigener Ehrgeiz solche Hobby Projekte, mich und meine Kenntnisse weiter zu verbessern.

Optimierungen, es schneller oder hübscher machen, steht bei mir meist am Ende der Wunschliste, wenn keine anderen wichtigeren Baustellen mehr offen sind, aber wird auf jeden Fall noch kommen.

Mehr dazu dann heute Abend .o)

Liebe Grüße,

Harald Frank

Pustekuchen

Hallo AspirinJunkie,

deine Beispiele und Erklärungen waren äußerst hilf und lehrreich. Ich habe methodisch deine Beispiele alle in die Unit Tests mit aufgenommen und diese im neuen Update auf die v1.2.0 erfolgreich umgesetzt. Es ist mir sehr wichtig das "false positive" Fehler gefunden und behoben werden, diese keinen Anwender auf eine falsche Fährte in der Analyse führen, vielen lieben Dank dafür .o)

Am Thema der Optimierung konnte ich beim aktuellen Ansatz knappe 9% an Geschwindigkeit raus holen, weniger als ich dachte, aber mehr als ich gehofft habe.

Solltest du oder andere noch weitere Anmerkungen, Tipps, Verbesserungsvorschläge oder Bug Reports haben, immer her damit .o)

Liebe Grüße,

Harald Frank