gerufenes Objekt »128« ist keine Funktion und das bedeutet was?

[Ben S. (patersigmund)]

Hallo allerseits!

Hab den bislang merkwürdigsten Fehler produziert der mir je 
untergekommen ist. Und zwar geht es um folgende Zeile

board.c:112: Fehler: gerufenes Objekt »128« ist keine Funktion

Der Code der für das Ganze verantwortlich ist hängt im Anhang.

Vielleicht hat ja wer ne Ahnung was der Fehler zu bedeuten hat. Denn 
google schmeisst dazu irgendwie nichts raus.

Danke schonmal im voraus.

Gruß,
  me

[Yalu X. (yalu) (Moderator)]

In der Zeile davor fehlt das Semikolon.

(1 << UP) ergibt 128, und PORT_OUT expandiert zu irgendetwas, was mit
einer öffnenden Klammer beginnt. Das ganze

  (128)(...)

sieht dann wie ein Funktionsaufruf aus, wobei (128) aber keine Funktion
ist. Darüber beschwert sich der Compiler :)

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

Benjamin S. schrieb:
> Denn
> google schmeisst dazu irgendwie nichts raus.

Wenn überhaupt, müsstest du wohl auf die deutschen Fehlermeldungen
verzichten und englische nehmen.

Yalu X. schrieb:
> In der Zeile davor fehlt das Semikolon.

Good catch. ;-)

Sieht man übrigens besser, wenn man den Code mal über den
Präprozessor schickt:

 (*(volatile uint8_t *)((0x0B) + 0x20)) |= ( 1<<2 ) | ( 1<<3 ) | ( 1<<4) | ( 1<<7 )
 (*(volatile uint8_t *)((0x0B) + 0x20)) &= ~( 1<<5 ) & ~( 1<<6 );

Durch das felehnde Semikolon entsteht für den Compiler dann sowas
(mal ein paar Konstanten zusammengefasst):

*(volatile uint8_t *)0x2B |= 28 | 128(*(volatile uint8_t *)(0x2B)) &= ~( 1<<5 ) & ~( 1<<6 )

Jetzt sollte auch klar werden, warum der Compiler dann versucht hat,
128 als Funktion aufzurufen.

[Ben S. (patersigmund)]

Ja super! Danke für die fixen Antworten und die Ausführliche Erklärung. 
So klapts dann auch mim gcc.

[Peter D. (peda)]

Die C-Syntax erlaubt schon recht verblüffende Konstrukte.

Man kann durchaus eine feste Adresse als Funktion casten, z.B. um eine 
Funktion im Bootloader aufzurufen.

Auch sollte man immer daran denken, daß das Zeilenende unter C kein 
Syntaxelement ist, d.h. die Fehlermeldung kann ihre Ursache in den 
Zeilen davor haben.


Peter

[Rolf Magnus (Gast)]

Peter Dannegger schrieb:
> Auch sollte man immer daran denken, daß das Zeilenende unter C kein
> Syntaxelement ist, d.h. die Fehlermeldung kann ihre Ursache in den
> Zeilen davor haben.

Nicht nur das. Auch ein #include bringt solche Fallstricke mit. Der 
Fehler kann also sogar in einer anderen Datei sein, die man vorher mal 
per #include eingebunden hat.

[Ben S. (patersigmund)]

Rolf Magnus schrieb:
> Auch ein #include bringt solche Fallstricke mit. Der
> Fehler kann also sogar in einer anderen Datei sein, die man vorher mal
> per #include eingebunden hat.

Aber ich mein der gcc haut dich dann aber an, wenn der Fehler in nem 
anderen Header ist.

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

Benjamin S. schrieb:

> Aber ich mein der gcc haut dich dann aber an, wenn der Fehler in nem
> anderen Header ist.

Das Problem ist ja, dass der Fehler gar nicht im Header selbst sitzt,
zumindest nicht aus Sicht des C-Compilers.  Stell dir mal die Datei
a1.h mit folgendem Inhalt vor:

typedef struct {
  char foo;
  int bar;
} mumble

und dann ein main.c mit:

#include "a1.h"

int
main(void)
{
  return 42;
}

Wenn du das compilieren willst, bekommst du:

$ cc -Os -c main.c
main.c:3: error: syntax error before "int"

[Ben S. (patersigmund)]

Ok auch nicht schlecht. Hätt ich jetzt nicht gedacht, denn bislang hat 
ich solche Fehler noch nicht.