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

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

1

  (128)(...)

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

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:

1

 (*(volatile uint8_t *)((0x0B) + 0x20)) |= ( 1<<2 ) | ( 1<<3 ) | ( 1<<4) | ( 1<<7 )

2

 (*(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):

1

*(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.

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

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 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.

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:

1

typedef struct {

2

  char foo;

3

  int bar;

4

} mumble

und dann ein main.c mit:

1

#include "a1.h"

2

3

int

4

main(void)

5

{

6

  return 42;

7

}

Wenn du das compilieren willst, bekommst du:

1

$ cc -Os -c main.c

2

main.c:3: error: syntax error before "int"

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