Deadlock in Übersetzungsdurchgang

[Jan R. (janra)]

Moin,
seit einiger Zeit stochere ich hieran herum, finde aber keinen neuen 
Ansatz oder gar eine Lösung dafür. Bitte schaut mal mit Kenneraugen 
darauf.

$ make 
Building Library
Building Lichterkette
Lichterkette.c: In function 'changeColorsInLEDs':
Lichterkette.c:46:5: error: 'led' undeclared (first use in this function)
     led[i].r = 0;    led[i].g = 0;    led[i].b = 0;
     ^
Lichterkette.c:46:5: note: each undeclared identifier is reported only once for each function it appears in
Lichterkette.c: In function 'main':
Lichterkette.c:66:14: warning: unused variable 'led' [-Wunused-variable]
  struct cRGB led[ramPrefs.numLED]; 
              ^
make: *** [Lichterkette] Error 1
$

Die Lib, die hier erfolgreich gebaut wurde, ist die ws2812b von Tim, die 
hier ja in einigen Threads behandelt wird.

Diese Compilerbeschwerden sind natürlich kein Einzelfall, auch hier im 
Forum tauchen die auf, jedoch waren die gesichteten Fälle stets 
vergessene #define oder kleinere Unachtsamkeiten.

Mein Code übersetzte tadellos bis zu dem Zeitpunkt, als ich die 
Codeschnipsel für die Fälle 'd' und 'n' in die Funktion 
changeColorsInLEDs() auslagerte. Jetzt motzt der Compiler, daß eben eine 
Deklaration noch nicht erfolgt sei. Wenn ich die Funktion, die zZt 
oberhalb der main() liegt, einfach mal nach ganz unten packe, kriege ich 
dieselben Beschwerden, nur mit vertauschter Reihenfolge von Warning und 
Error und mit anderen Zeilennummern. Die Strategie des gcc ist scheinbar 
nicht vom Anfang bis zum Ende.

Der banale Tip bzw. Ansatz wäre, die Fkt. changeColorsInLEDs() doch 
wieder einfach seinzulassen und deren Codehappen zurück in main() zu 
packen. Der ist aber sehr ungeeignet, da ich ja noch einiges mehr in die 
Fkt. reinpacken will und damit redundanten Code vermeiden will und eig. 
alles erreichen will, warum man Funktionen baut.

Wie kriege ich diesen Deadlock weg?

VG, Jan.

[Peter II (Gast)]

Wenn led erst in main angelegt wird, kannst du nicht einfach global 
darauf zugeifen.

Da musst du schon led global machen.

[Jörg W. (dl8dtl) (Moderator)]

Nun, eine lokale Variable der Funktion main() ist nunmal nur
innerhalb dieser sichtbar.  Die kannst du nicht in einer völlig
anderen Funktion bearbeiten.

Zwei Möglichkeiten:

* Die Variable “led” global (bzw. modulintern) definieren.

* Einen Zeiger auf die (main()-lokale) Variable beim Aufruf der Funktion
übergeben, und dort die Variable über diesen Zeiger manipulieren.

[Karl H. (kbuchegg)]

Jan R. schrieb:

> Die Strategie des gcc ist scheinbar
> nicht vom Anfang bis zum Ende.

Doch, die ist es.
Aber nicht so, wie du dir das vorstellst, dass die Aufrufhierarchie die 
Richtung vom Anfang bis zum Ende definiert, sondern viel banaler:
Da gibt es ein Textfile, das wird von der ersten Zeile bis zur letzten 
Zeile gelesen. In genau dieser Reihenfolge. Von oben nach unten. Einfach 
nur Text. Nicht mehr.

>
> Der banale Tip

Der banale Tip wäre, ganz einfach mal C zu lernen anstatt deine 
Unkentniss dem Compiler in die Schuhe schieben zu wollen. Und diese 
'Strategie' solltest du dir besser erst mal zu eigen machen: Wenn der 
Compiler dir einen Fehler meldet, dann hast DU einen Fehler gemacht 
und nicht der Compiler. Die Wahrscheinlichkeit, dass du auf deinem Level 
einen Compilerfehler findest, ist nahezu bei 0. Bis auf weiteres gilt: 
Der Compiler kann wesentlich besser C als du.

void foo()
{
  i = 5;
}

int main()
{
  int i;

  foo();
}

die Variable i ist funktionslokal. Ausserhalb von main existiert sie 
nicht. foo ist ausserhalb von main(). Wie also soll der Zugriff aus foo 
heraus erfolgen?

[Jan R. (janra)]

Danke für die konstruktiven Antworten.
An den Scope hatte ich kein Bißchen gedacht hierbei.
Da hatte ich echt Tomaten auf den Augen.
VG, Jan.

[Peter D. (peda)]

Jan R. schrieb:
> Lichterkette.c:46:5: error: 'led' undeclared (first use in this
> function)

Jan R. schrieb:
> Lichterkette.c:66:14: warning: unused variable 'led' [-Wunused-variable]

Ich bin immer wieder begeistert, wie exakt die Fehlermeldungen sind.
Die Leute geben sich richtig Mühe, mit dem Finger genau auf den Fehler 
zu zeigen.