- √ - lokale Variable....

[EPIX]

ich habe folgenden Code in meiner "Privat-Lib"

////////////////////////////////////////////////////////////////////////////////////
// LOG-Stati
:begin hoeFlushState(FlushState)
:info $Klartext-Statusmeldung aus FTP-Rückgabe-Status$ \\
		$FlushState$...Status (u08)$
:shortinfo $Klartext-Statusmeldung$

:var hoeFlushStateTxt@

	if FlushState==0 then hoeFlushStateTxt@=$Erfolgreich ($+convert(FlushState,$$)+$)$ endif
	if FlushState==1 then hoeFlushStateTxt@=$Server nicht erreichbar ($+convert(FlushState,$$)+$)$ endif
	if FlushState==2 then hoeFlushStateTxt@=$Fehler beim Hochladen der Datei($+convert(FlushState,$$)+$)$ endif
	if FlushState==3 then hoeFlushStateTxt@=$Passwort/User nicht erlaubt($+convert(FlushState,$$)+$)$ endif
	if FlushState==4 then hoeFlushStateTxt@=$Fehler Verzeichnis nicht existent/konnte nicht angelegt werden($+convert(FlushState,$$)+$)$ endif
	if FlushState==5 then hoeFlushStateTxt@=$Übertragung wird durchgeführt ($+convert(FlushState,$$)+$)$ endif

:return hoeFlushStateTxt@
:end

und erhalten die Fehlermeldung:

Laufzeitfehler:
! Variable nicht definiert: >__hoeFlushState_36__hoeFlushStateTxt< !
ID:11

Ich sitz' jetzt schon seit längerer Zeit: WAS WILL MIR DER COMPILER SAGEN???

in der tmpMacroFuncOut.txt kommt zwar die monierte Variable vor, aber was soll ich im Code ändern??

[EPIX]

wenn man den Code wie folgt erweitert

:var hoeFlushStateTxt@
hoeFlushStateTxt@=$$

funktioniert es....

Ist ein bisserl "schräg" die Fehlermeldung - aber jetzt geht es ja...

[Uwe!]

"Variable nicht definiert" passt da doch aber wie die Faust aufs Auge. Jede Variable muss vor Benutzung im EibPC doch definiert werden.

[EPIX]

jo eh....

was ist denn :var hoeFlushStateTxt@
("könnte" man ja fast als Definition verstehen, wenn es vielleicht ja gleich

:var hoeFlushStateTxt@=$$

sein dürfte....)

und welche Variable passt den Compiler nicht?

__hoeFlushState_36__hoeFlushStateTxt

wie Faust auf Auge - lieber wäre mir eine präzise Fehlermeldung statt "Faustwatschen"

[klaus_kraemer]

Lokale Variable und Deklaration / Initialisierung

Zum Thema der lokalen Variablen hatte ich schon mal dort
https://knx-user-forum.de/eibpc/3433...-pass-ref.html
geschrieben.

Ich versteh's halt nicht, dass eine lokale Variable über zwei Codezeilen hinweg definiert werden muss, wenn normale Variable innerhalb einer Zeile deklariert und initialisiert werden. Ich habe ewig gebraucht, um mit der Fehlermeldung

"Lokale Makrovariablen haben am Ende ein "@" Zeichen und werden zeilenweise getrennt definiert."

zu realisieren, was eigentlich erforderlich ist,

denn
:var boolAutoswitch@ = AUS
:var strWebOutTeich@ = $$

entsprach doch genau dem, was die Fehlermeldung beschrieb.

Vielleicht kann die Weiterentwicklung des EibStudio künftig ja wenigstens beide Möglichkeiten erlauben - denn ich bin sicher, hier nicht der einzige gewesen zu sein, der da Zeit und Nerven versch...en hat.

[cds]

@EPIX

Ganz ehrlich: Dein Originalscript hat ohnehin die PfuiBäh-Medallie am goldenen Band verdient.
Sehr vorbildlich das der Compiler meckert.

Was soll denn das arme Script machen wenn Flushstate nicht im Bereich von 0-5 liegt - denn definiert ist es als U8. Dann ist der Rückgabewert "irgendwas was zufällig noch im Speicher steht".

Von daher ist eine saubere Initialisierung des Rückgabewertes Pflicht - egal in welcher Sprache !

Gruß

Carsten

[EPIX]

@cds
keine Ahnung was du meinst....

Was soll denn das arme Script machen wenn Flushstate nicht im Bereich von 0-5 liegt

dann ist es ein Bug von Enertex
weil: wie man durch sinnerfassendes Lesen des Handbuches feststellen kann, GIBT es keine Werte außerhalb 0-5

und "vorbildlich" wäre es wenn die Fehlermeldung nicht

Variable nicht definiert: >__hoeFlushState_36__hoeFlushStateTxt< !

sondern die korrekte Variable, nämlich "hoeFlushStateTxt@" anmaulen würde - ODER??

deine "PfuiBäh-Medallie am goldenen Band" nehme ich gerne an,
insbesonders wenn du mir ein paar deiner sicherlich didaktisch sehr wertvollen Beispiel-Makros als Vorbilder zur Verfügung stellst....

[cds]

Hallo!

Erkläre ich dir gerne, und du lieferst nämlich zufällig selber schon das beste Beispiel warum man solchen Code NICHT schreibt:

$FlushState$ ist eine Variable vom Typ u08.
Das ist die Info die der Compiler über selbige hat, das bedeutet sie kann alle Werte von 0 bis 255 annehmen.

Die Tatsache, das aufgrund ihrer Verwendung gar nicht der ganze Wertebereich benutzt wird ändert daran nichts. Dem Compiler (und das hat auch nix mit Enertex zu tun sondern ist in allen Sprachen so) ist das völlig wurst - und nichtmal bekannt.

Nun sieht der Compiler, es gibt da eine Variable "hoeFlushStateTxt@". Dummerweise enthalten in der Enertex Sprache die Variablendeklarationen keinen Typ, d.H. der Compiler weiß erst mal nur das es eine Variable diesen Namens gibt, aber nicht was für ein Typ dies ist. Das wird erst bei der Zuweisung klar.
In deinem Makro aber ist gar nicht garantiert das dieser Variable jemals etwas zugewiesen wird, da du Zuweisungen nur für die Werte 0-5 machst.
Somit weiß der Compiler auch nicht was er denn überhaupt irgendie zurück geben soll.
Du gibst übrigens selber das perfekte Beispiel warum man Variablen IMMER initialisieren muss: Laut meinem Handbuch kann der FTPState Werte von 0-6 annehmen. Was soll dein Script also bei "6" machen? Das übergeben von Typfreien Variablen gibt es bei Enertex nicht (das ginge so in die Richtung voidpointer - der in den Sprachen in denen es sowas gibt auch immer genug Potential für Probleme bietet).
Die von dir zugefügte Zuweisung von $$ - also einem leeren String - zu hoeFlushStateTxt@ macht klar das dies eine Variable vom Typ String ist. Damit kann der Compiler arbeiten.

Nun aber zu der Fehlermeldung die du bekommen hast, auch diese ist leicht erklärbar (auch wenn für den Anwender nicht schön):

Nachdem du eine lokale Variable verwendest kann der Compiler hier nicht einfach den Variablennamen verwenden, denn genau dieser Name könnte zulässiger Weise noch mehrfach lokal, also auch einmal global verwendet werden. Also generiert der Compiler interne Namen für die Variablen um diese auseinander zu halten. Das ist dann "__hoeFlushState_36__hoeFlushStateTxt". Offensichtlich der Makroname, dann ein Zähler, und dann der eigentliche Variablenname.

Ich würde dies nicht als Bug sehen - ein Programmierer kommt mit sowas klar. Ganz im Gegenteil würde ich eine Reduzierung auf den Variablennamen alleine ablehnen, da somit sehr leicht der Kontext verloren geht - oder falsch gedeutet wird.

Ich hoffe das war verständlich.

Gruß

Carsten

[saft6luck]

Erkläre ich dir gerne, und du lieferst nämlich zufällig selber schon das beste Beispiel warum man solchen Code NICHT schreibt:

Es wäre wirklich schön, wenn du generell erst mal erklären würdest, was du so schlecht findest anstatt "ach so lustige" Medaillen zu verteilen.

Die Tatsache, das aufgrund ihrer Verwendung gar nicht der ganze Wertebereich benutzt wird ändert daran nichts. Dem Compiler (und das hat auch nix mit Enertex zu tun sondern ist in allen Sprachen so) ist das völlig wurst - und nichtmal bekannt.

Nun sieht der Compiler, es gibt da eine Variable "hoeFlushStateTxt@". Dummerweise enthalten in der Enertex Sprache die Variablendeklarationen keinen Typ, d.H. der Compiler weiß erst mal nur das es eine Variable diesen Namens gibt, aber nicht was für ein Typ dies ist. Das wird erst bei der Zuweisung klar.
In deinem Makro aber ist gar nicht garantiert das dieser Variable jemals etwas zugewiesen wird, da du Zuweisungen nur für die Werte 0-5 machst.
Somit weiß der Compiler auch nicht was er denn überhaupt irgendie zurück geben soll.

Du gibst übrigens selber das perfekte Beispiel warum man Variablen IMMER initialisieren muss: Laut meinem Handbuch kann der FTPState Werte von 0-6 annehmen. Was soll dein Script also bei "6" machen?

Dir missfällt also, dass nicht alle Werte geprüft werden, der Code also nicht robust ist. Alternativ könntest du auch mit einer entsprechenden Initialisierung von "hoeFlushStateTxt@" leben. Weißt du überhaupt, ob die Initialisierung dieser lokalen Variable dann jedes mal bei Aufruf ausgeführt wird oder nur einmal beim 1. Durchlauf?

Das übergeben von Typfreien Variablen gibt es bei Enertex nicht (das ginge so in die Richtung voidpointer - der in den Sprachen in denen es sowas gibt auch immer genug Potential für Probleme bietet).
Die von dir zugefügte Zuweisung von $$ - also einem leeren String - zu hoeFlushStateTxt@ macht klar das dies eine Variable vom Typ String ist. Damit kann der Compiler arbeiten.

Das könnte er auch so erkennen, anhand der Verwendung im Code (nichts anderes ist die Deklaration über eine Zuweisung), wenn man es denn einbauen würde.

Nun aber zu der Fehlermeldung die du bekommen hast, auch diese ist leicht erklärbar (auch wenn für den Anwender nicht schön):

Nachdem du eine lokale Variable verwendest kann der Compiler hier nicht einfach den Variablennamen verwenden, denn genau dieser Name könnte zulässiger Weise noch mehrfach lokal, also auch einmal global verwendet werden. Also generiert der Compiler interne Namen für die Variablen um diese auseinander zu halten. Das ist dann "__hoeFlushState_36__hoeFlushStateTxt". Offensichtlich der Makroname, dann ein Zähler, und dann der eigentliche Variablenname.

Und hier ist das Problem. Wie soll ein "Programmierer" vom Niveau eines "normalen Anwenders" (und hierfür soll die Programmiersprache gedacht sein) denn darauf kommen? Dieser "Trick", für lokale Variablen einfach auch wieder globale Variablen zu verwenden, ist nun einmal sehr ungewöhnlich und ganz sicher nicht selbsterklärend!

Dass du das verstanden hast, heißt nicht, dass das jeder so verstehen muss und sicherlich folgert daraus, dass man diese Fehlermeldung eben nicht versteht. Und darum geht es dann.

Ich würde dies nicht als Bug sehen - ein Programmierer kommt mit sowas klar. Ganz im Gegenteil würde ich eine Reduzierung auf den Variablennamen alleine ablehnen, da somit sehr leicht der Kontext verloren geht - oder falsch gedeutet wird.

Auch als Programmierer kommt man damit nicht klar, denn laut Handbuch ist die Definition vorhanden, es fehlt ja die "Initialisierung" auf der Hauptebene. Das beliebige mischen von Definition, Deklaration und Initialisierung als Ersatz der ersteren führt zwangsläufig zur Verwirrung beim Anwender. Zumal insbesondere :var im Handbuch als Definition einer lokalen Variablen bezeichnet wird.

[cds]

Dir missfällt also, dass nicht alle Werte geprüft werden, der Code also nicht robust ist. Alternativ könntest du auch mit einer entsprechenden Initialisierung von "hoeFlushStateTxt@" leben. Weißt du überhaupt, ob die Initialisierung dieser lokalen Variable dann jedes mal bei Aufruf ausgeführt wird oder nur einmal beim 1. Durchlauf?

Die Initialisierung dient in diesem Fall ja im wesendlichen dazu der Variable auch einen Typ zuzuweisen - denn genau darüber beschwert sich ja der Compiler.
Dafür ist es völlig ausreichend wenn dies einmal geschieht. Lediglich wäre danach der Inhalt nicht zwingend korrekt.
Richtig, das ist nicht robust, aber zumindest typsicher.

Das könnte er auch so erkennen, anhand der Verwendung im Code (nichts anderes ist die Deklaration über eine Zuweisung), wenn man es denn einbauen würde.

Das erkennt er ja auch genau so - aber eben nur wenn er auch SICHER erkennen kann was denn mit der Variablen geschieht.
In dem Fall das die Variable erst dann initialisiert wird wenn eine von 5 (von 256) möglichen Bedingungen erfüllt ist kann der Compiler das eben gerade nicht.
Hätte einer If-clause noch ein Else sollte der Compiler zufrieden sein.

Es ist nicht die Aufgabe des Compilers zu erraten was sich vielleicht der Programmierer mal gedacht haben könnte.
Da gab es in der Tat mal eine Sprache die das gemacht hat. Rate mal warum diese wieder verschwunden ist ...

Und hier ist das Problem. Wie soll ein "Programmierer" vom Niveau eines "normalen Anwenders" (und hierfür soll die Programmiersprache gedacht sein) denn darauf kommen? Dieser "Trick", für lokale Variablen einfach auch wieder globale Variablen zu verwenden, ist nun einmal sehr ungewöhnlich und ganz sicher nicht selbsterklärend!

Der EibPC hat nun einmal den Anspruch komplex programmiert zu werden. Das erfordert es schlichtweg sich mit den Prinzipien der Programmierung zu beschäftigen.
In wieweit der "normale Anwender" das schafft ist sehr individuell.
Ich stimme aber zu das die Doku hier besser sein könnte.
Dieser "Trick" Tokens bzw. Symbole zu verwenden ist das Standardverfahren hierfür. Kein mir bekannter Compiler macht das anders.

Auch als Programmierer kommt man damit nicht klar, denn laut Handbuch ist die Definition vorhanden, es fehlt ja die "Initialisierung" auf der Hauptebene. Das beliebige mischen von Definition, Deklaration und Initialisierung als Ersatz der ersteren führt zwangsläufig zur Verwirrung beim Anwender. Zumal insbesondere :var im Handbuch als Definition einer lokalen Variablen bezeichnet wird.

Also mir als Programmierer ist klar das es hier nur zwei Möglichkeiten gibt:

1. Die Sprache verwendet einen großen Standardtyp - außer man deklariert explizit was anderes (Matlab macht es beispielsweise so).
Diese Variante fällt für den EibPC flach, da der Speicherbedarf dann viel zu hoch wäre da man ja immer die maximal mögliche Variablengröße annehmen müsste (f32).

2. Der Compiler kennt den Typ erst dann wenn er irgendwie zugewiesen wurde.

Einem "Programmierer" muß klar sein das ein ":var" dies nicht tut.

[saft6luck]

Das erkennt er ja auch genau so - aber eben nur wenn er auch SICHER erkennen kann was denn mit der Variablen geschieht.
In dem Fall das die Variable erst dann initialisiert wird wenn eine von 5 (von 256) möglichen Bedingungen erfüllt ist kann der Compiler das eben gerade nicht.
Hätte einer If-clause noch ein Else sollte der Compiler zufrieden sein.

Es ist nicht die Aufgabe des Compilers zu erraten was sich vielleicht der Programmierer mal gedacht haben könnte.
Da gab es in der Tat mal eine Sprache die das gemacht hat. Rate mal warum diese wieder verschwunden ist ...

Das hat nichts mit "erraten" zu tun. Der Compiler muss jeden Teil des Codes auf Richtigkeit prüfen. Dies gilt vor allem auch für die Typrichtigkeit der Zuweisungen.

Nach deiner Vorstellung würde der Compiler ja auch keine Fehler ausgeben, wenn die Variable zwar Deklariert ist, sie in if-clauses aber anders verwendet wird.

Da diese Prüfung also durchgeführt werden muss, könnte er die erste Zuweisung als Typdeklaration verwenden, die er findet und dann als Referenz für alle weiteren verwenden.

Und das wäre genauso richtig, wie die über die zusätzliche Initialisierung. Es gäbe bzgl. des Typs keinen Unterschied.

Der einzige Unterschied ist also die Initialisierung, deren Fehlen dich aber doch nicht stört?

Der EibPC hat nun einmal den Anspruch komplex programmiert zu werden. Das erfordert es schlichtweg sich mit den Prinzipien der Programmierung zu beschäftigen.
In wieweit der "normale Anwender" das schafft ist sehr individuell.

Das kannst du ja mal mit Michael abstimmen. Er sieht das sicherlich anders!

Dieser "Trick" Tokens bzw. Symbole zu verwenden ist das Standardverfahren hierfür. Kein mir bekannter Compiler macht das anders.

Wovon redest du? Dieser Trick wird ganz sicher nicht für lokale Variablen verwendet. Üblicherweise kommen lokale Variablen auf den Stack.

Also mir als Programmierer ist klar das es hier nur zwei Möglichkeiten gibt:

1. Die Sprache verwendet einen großen Standardtyp - außer man deklariert explizit was anderes (Matlab macht es beispielsweise so).
Diese Variante fällt für den EibPC flach, da der Speicherbedarf dann viel zu hoch wäre da man ja immer die maximal mögliche Variablengröße annehmen müsste (f32).

2. Der Compiler kennt den Typ erst dann wenn er irgendwie zugewiesen wurde.

Einem "Programmierer" muß klar sein das ein ":var" dies nicht tut.

Abgesehen davon, dass weder Matlab noch Visual Basic und Konsorten, die universelle Datentypen kennen, tatsächlich einen universellen Datentyp verwenden, sondern vielmehr vorher den Code analysieren und dann den benötigten Datentyp verwenden, ist der eibPC-Anwender auf die Hilfsmittel EibStudio und Anleitung angewiesen.

Wenn dort steht: ":var" definiert eine Lokale Variable und der Kompiler meckert "Lokale Variable nicht definiert", obwohl der Variablenname sowieso nicht verwendet wurde und das ":var" vorhanden ist, dann darf man sich schon fragen was der Kompiler will.

Wenn es einem Programmierer klar sein muss, sollte es halt im Handbuch stehen. Da gibt es keinen Hinweis, nicht einmal ein entsprechendes Beispiel.

[kermit42]

Spannende Diskussion ...
Zu einem muss ich auch noch meinen Senf dazugeben:

...
Üblicherweise kommen lokale Variablen auf den Stack.
...

Das stimmt natürlich, wenn ich einen "richtigen" Funktionsaufruf z.B. in einem C-Programm habe und die Variable nicht Static ist. Aber wenn ich das richtig verstanden habe passiert bei einem Makro nur eine Textersetzung, wie sie z.B. beim C-Preprozessor benutzt wird. Daher denke ist, dass das nicht verleichbar ist mit einem Funktionsaufruf und daher die Variable auch nicht auf dem Stack liegt, d.h. nur pseudo-lokal ist.

Ciao, Peter

[saft6luck]

Das stimmt natürlich, wenn ich einen "richtigen" Funktionsaufruf z.B. in einem C-Programm habe und die Variable nicht Static ist. Aber wenn ich das richtig verstanden habe passiert bei einem Makro nur eine Textersetzung, wie sie z.B. beim C-Preprozessor benutzt wird. Daher denke ist, dass das nicht verleichbar ist mit einem Funktionsaufruf und daher die Variable auch nicht auf dem Stack liegt, d.h. nur pseudo-lokal ist.

Klar, aber wenn wir schon von "üblicherweise" reden, dann werden bestimmt keine Token verwendet, sondern die Variablen am Stack abgelegt.

Carsten toppt das in Bezug auf Token ja sogar noch: "Kein mir bekannter Compiler macht das anders."

[cds]

Das hat nichts mit "erraten" zu tun. Der Compiler muss jeden Teil des Codes auf Richtigkeit prüfen. Dies gilt vor allem auch für die Typrichtigkeit der Zuweisungen.

Nach deiner Vorstellung würde der Compiler ja auch keine Fehler ausgeben, wenn die Variable zwar Deklariert ist, sie in if-clauses aber anders verwendet wird.

Das habe ich nirgends behauptet. Ich sage lediglich das die Festlegung eines Variablentyps eindeutig sein muß. Selbstverständlich findet in if-clauses eine Typprüfung statt, aber eben keine Deklaration bzw. Typisierung.

Da diese Prüfung also durchgeführt werden muss, könnte er die erste Zuweisung als Typdeklaration verwenden, die er findet und dann als Referenz für alle weiteren verwenden.

Und das wäre genauso richtig, wie die über die zusätzliche Initialisierung. Es gäbe bzgl. des Typs keinen Unterschied.

Nein, das wäre keineswegs genau so richtig. Die typisierung einer Variable muss eindeutig sein. Das ist sie wenn
- der Typ direkt bei der Deklaration festgelegt wird
- der Typ bei der ersten Verwendung festgelegt wird.

Das Problem ist jetzt: Bei einer Typisierung in einer if-clause ist eben zur Compilierzeit gar nicht klar welche Verwendung denn nun die Erste ist.

Hier jetzt einfach die Krücke zu nehmen, und zu definieren das das textuell erste Auftreten einer Zuweisung verwendet wird macht nix besser, denn die resultierend Fehlermeldung würde dann zwar die erste Verwendung mit anderem Typ anzeigen.
Das würde einer eindeutigen Fehlermeldung auch nicht helfen, denn niemand sagt das die textuell erste Verwendung richtig ist.

Und jetzt komm mit bitte nicht mit polymorphismus, denn gibt's im EibPC nicht.

Der einzige Unterschied ist also die Initialisierung, deren Fehlen dich aber doch nicht stört?

Der einzige Unterschied ist die deterministische Festlegung des Typs, und die ist eben nur an einer Codestelle gegeben die auch garantiert durchlaufen wird - also nichts was an eine Bedingung geknüpft ist.

Das kannst du ja mal mit Michael abstimmen. Er sieht das sicherlich anders!

Glaube ich nicht. Die Sprache des EibPC ist zweifelsohne darauf getrimmt möglichst einfach zu sein, es bleibt aber eine Programmiersprache. Wer EibPC programmieren kann, der kommt auch mit VisualBasic klar.

Wovon redest du? Dieser Trick wird ganz sicher nicht für lokale Variablen verwendet. Üblicherweise kommen lokale Variablen auf den Stack.

Kann man so pauschal auch nicht immer sagen. Das Hauptproblem hier ist aber das die lokalen Variablen ja in Wirklichkeit gar keine sind. Du darfst nicht vergessen das es in EibPC keine Funktionen gibt, sondern das Macros sind. Und was sind Macros?
Codeblöcke die vom Preprocessor letztlich unter einsetzen der Blockparameter in den ursprünglichen Sourcecode copieren.

Die hier sog. "Lokalen Variablen" existieren somit also in Wirklichkeit global - nur sorgt der Preprocessor dafür das die als "Macro local" markierten Variablen wirklich nur an einer Stelle verwendet werden - durch das Generieren von unterschiedlichen globalen Namen.

Abgesehen davon, dass weder Matlab noch Visual Basic und Konsorten, die universelle Datentypen kennen, tatsächlich einen universellen Datentyp verwenden, sondern vielmehr vorher den Code analysieren und dann den benötigten Datentyp verwenden, ist der eibPC-Anwender auf die Hilfsmittel EibStudio und Anleitung angewiesen.

Nun, gerade Matlab analysiert gar nix, sondern verwendet intern immer ein f32 - außer es ist explizit etwas anderes deklariert.
Macht dort ja auch nix - Speicher ist da ja kein Problem.

Wenn dort steht: ":var" definiert eine Lokale Variable und der Kompiler meckert "Lokale Variable nicht definiert", obwohl der Variablenname sowieso nicht verwendet wurde und das ":var" vorhanden ist, dann darf man sich schon fragen was der Kompiler will.

Wenn es einem Programmierer klar sein muss, sollte es halt im Handbuch stehen. Da gibt es keinen Hinweis, nicht einmal ein entsprechendes Beispiel.

DAS ist allerdings richtig. Wie ich schon sagte: Das ist kein Compilerproblem, sondern ein Dokumentationsproblem.

[cds]

Klar, aber wenn wir schon von "üblicherweise" reden, dann werden bestimmt keine Token verwendet, sondern die Variablen am Stack abgelegt.

Carsten toppt das in Bezug auf Token ja sogar noch: "Kein mir bekannter Compiler macht das anders."

Nun mal langsam: Das habe ich so nicht gemeint. Ich habe gesagt: Jeder Compiler verwendet intern nicht die Klarnamen der Variablen aus dem Sourcecode, sondern generiert daraus eigene Symbole.

Ich wollte in DIESER Diskussion jetzt nicht noch einwerfen das echte lokale Variablen ja üblicherweise auf dem Stack liegen. Das fürht hier vielleicht doch ein bischen weit.