Funktionspointer Deklaration xhuge Problem / KEIL Compiler

a.wojciech Gast #2133198
Lesenswert?
• ▲
▼ 
Ich habe da ein interessantes Problem mit meinem KEIL Compiler.

Bei der Umstellung von huge auf xhuge fliegen mir ein paar 
Funktionspointerdeklarationene um die Ohren. Von der Syntax ist es 
soweit i.O. Vielleicht kann jemand von euch damit etwas anfangen:

Deklarationen:
static char USR_PTR_DATA(*s_pCallbackStart[USR_MAXCALLBACK])(void);
static char USR_PTR_DATA(*s_pCallbackStop[USR_MAXCALLBACK])(void);
static char USR_PTR_DATA(*s_pCallbackDebugLoop[USR_MAXCALLBACK])(void);
static char USR_PTR_DATA(*s_pCallbackInt0[USR_MAXCALLBACK])(void);
static char USR_PTR_DATA(*s_pCallbackInt1[USR_MAXCALLBACK])(void);
static char USR_PTR_DATA(*s_pCallbackTaskNC[USR_MAXCALLBACK])(void);

Fehlermeldung des Compilers:


..\RTS\SRC\C\RTSEVENT.C(47): error C25: syntax error near '('
..\RTS\SRC\C\RTSEVENT.C(47): warning C34: 's_pCallbackStart': missing 
declaration specifiers
..\RTS\SRC\C\RTSEVENT.C(48): error C25: syntax error near '('
..\RTS\SRC\C\RTSEVENT.C(48): warning C34: 's_pCallbackStop': missing 
declaration specifiers
..\RTS\SRC\C\RTSEVENT.C(49): error C25: syntax error near '('
..\RTS\SRC\C\RTSEVENT.C(49): warning C34: 's_pCallbackDebugLoop': 
missing declaration specifiers
..\RTS\SRC\C\RTSEVENT.C(50): error C25: syntax error near '('
..\RTS\SRC\C\RTSEVENT.C(50): warning C34: 's_pCallbackInt0': missing 
declaration specifiers
..\RTS\SRC\C\RTSEVENT.C(51): error C25: syntax error near '('
..\RTS\SRC\C\RTSEVENT.C(51): warning C34: 's_pCallbackInt1': missing 
declaration specifiers
..\RTS\SRC\C\RTSEVENT.C(52): error C25: syntax error near '('
..\RTS\SRC\C\RTSEVENT.C(52): warning C34: 's_pCallbackTaskNC': missing 
declaration specifiers
..\RTS\SRC\C\RTSEVENT.C(56): error C25: syntax error near '('
..\RTS\SRC\C\RTSEVENT.C(56): warning C34: 's_pPlcFunctions': missing 
declaration specifiers
..\RTS\SRC\C\RTSEVENT.C(179): error C72: sizeof returns zero
..\RTS\SRC\C\RTSEVENT.C(192): error C72: sizeof returns zero
..\RTS\SRC\C\RTSEVENT.C(205): error C72: sizeof returns zero
..\RTS\SRC\C\RTSEVENT.C(218): error C72: sizeof returns zero
..\RTS\SRC\C\RTSEVENT.C(231): error C72: sizeof returns zero
..\RTS\SRC\C\RTSEVENT.C(244): error C72: sizeof returns zero
..\RTS\SRC\C\RTSEVENT.C(259): warning C72: sizeof returns zero
..\RTS\SRC\C\RTSEVENT.C(260): warning C72: sizeof returns zero
..\RTS\SRC\C\RTSEVENT.C(261): warning C72: sizeof returns zero
..\RTS\SRC\C\RTSEVENT.C(262): warning C72: sizeof returns zero
..\RTS\SRC\C\RTSEVENT.C(263): warning C72: sizeof returns zero
..\RTS\SRC\C\RTSEVENT.C(264): warning C72: sizeof returns zero
..\RTS\SRC\C\RTSEVENT.C(375): error C72: sizeof returns zero
..\RTS\SRC\C\RTSEVENT.C(376): error C72: sizeof returns zero
..\RTS\SRC\C\RTSEVENT.C(376): warning C91: '=': pointer to different 
objects
..\RTS\SRC\C\RTSEVENT.C(378): error C72: sizeof returns zero
..\RTS\SRC\C\RTSEVENT.C(390): error C72: sizeof returns zero
..\RTS\SRC\C\RTSEVENT.C(391): error C72: sizeof returns zero
..\RTS\SRC\C\RTSEVENT.C(391): warning C91: '=': pointer to different 
objects
..\RTS\SRC\C\RTSEVENT.C(393): error C72: sizeof returns zero
..\RTS\SRC\C\RTSEVENT.C(405): error C72: sizeof returns zero
..\RTS\SRC\C\RTSEVENT.C(406): error C72: sizeof returns zero
..\RTS\SRC\C\RTSEVENT.C(406): warning C91: '=': pointer to different 
objects
..\RTS\SRC\C\RTSEVENT.C(408): error C72: sizeof returns zero
..\RTS\SRC\C\RTSEVENT.C(420): error C72: sizeof returns zero
..\RTS\SRC\C\RTSEVENT.C(421): error C72: sizeof returns zero
..\RTS\SRC\C\RTSEVENT.C(421): warning C91: '=': pointer to different 
objects
..\RTS\SRC\C\RTSEVENT.C(423): error C72: sizeof returns zero
..\RTS\SRC\C\RTSEVENT.C(435): error C72: sizeof returns zero
..\RTS\SRC\C\RTSEVENT.C(436): error C72: sizeof returns zero
..\RTS\SRC\C\RTSEVENT.C(436): warning C91: '=': pointer to different 
objects
..\RTS\SRC\C\RTSEVENT.C(438): error C72: sizeof returns zero
..\RTS\SRC\C\RTSEVENT.C(450): error C72: sizeof returns zero
..\RTS\SRC\C\RTSEVENT.C(451): error C72: sizeof returns zero
..\RTS\SRC\C\RTSEVENT.C(451): warning C91: '=': pointer to different 
objects
..\RTS\SRC\C\RTSEVENT.C(453): error C72: sizeof returns zero


Lieben Dank
André
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
Karl H. #2133221
Lesenswert?
• ▲
▼ 
OK

Ich weiß nicht, wie Keil dieses xhuge in den Compiler eingebaut hat, 
aber ich geh davon aus, dass die Entwickler das wie die normalen 
modifier (const und volatile) behandeln.

static char USR_PTR_DATA(*s_pCallbackStart[USR_MAXCALLBACK])(void);

Wenn ich das nach den C-Regeln auseinandernehme, dann ist das ein Array 
von Funktionspointern, wobei die Funktionen keine Argumente übernehmen 
und (Achtung jetzt kommts) einen Character returnieren, wobei der char 
im xhuge Memory liegt.

Huch? Ein Returntyp, der im xhuge Memory liegt? Das ergibt für mich so 
keinen wirklichen Sinn.

Daher solltest du dich IMHO fragen: Was will ich eigentlich haben? Wenn 
es die Funktionspointer sind, die im xhuge Memory liegen sollen, dann 
müsste man IMHO die Syntax variieren. Mein Vorschlag

static char (*s_pCallbackStart[USR_MAXCALLBACK])(void) USR_PTR_DATA;


Disclaimer: Ich hab vom Keil Compiler und dessen Syntaxerweiterung nicht 
wirklich Ahnung. Aber das ist das was ich aus Analogiegründen tun bzw. 
probieren würde. Basierend auf Annahmen, wie Keil die Implementierung 
von xhuge in ihre C-Syntax gemacht hat.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
(prx) A. K. #2133231
Lesenswert?
• ▲
▼ 
Karl Heinz Buchegger schrieb:

> Huch? Ein Returntyp, der im xhuge Memory liegt? Das ergibt für mich so
> keinen wirklichen Sinn.

Oftmals wird das in Compilern gegen Sinn und Verstand verschludert, so 
haben PC-Compiler traditionell für einen far-pointer
   int far *x;
statt des von der Sprachlogik her diktierten
   int *far x;
verwendet, was zwar schöner aussah, aber die Sache nicht wirklich 
vereinfachte.

Hier wäre aber erst einmal zu klären, ob das Array im xhuge Memory 
liegen soll oder ob die Pointer darauf zeigen sollen. Letzteres könnte 
dann möglicherweise
    void (xhuge *a[])(void);
sein. Nur müssten für xhuge und huge die gleichen Regeln gelten, daher 
meine Frage, ob das wirklich die einzige Änderung war.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Karl H. #2133243
Lesenswert?
• ▲
▼ 
A. K. schrieb:

> Oftmals wird das in Compilern gegen Sinn und Verstand verschludert, so
> haben PC-Compiler traditionell für einen far-pointer
>    int far *x;
> statt des von der Sprachlogik her diktierten
>    int *far x;
> verwendet, was zwar schöner aussah, aber die Sache nicht wirklich
> vereinfachte.

Ja leider.
Und gerade Microsoft hat sich bei solchen Dingen nicht gerade mit Ruhm 
bekleckert. Das berühmte void main() beispielsweise geht zu einem großen 
Teil ebenfalls auf das Konto von MS.


> Hier wäre aber erst einmal zu klären, ob das Array im xhuge Memory
> liegen soll oder ob die Pointer darauf zeigen sollen. Letzteres könnte
> dann möglicherweise
>     void (xhuge *a[])(void);
> sein.

Auch eine gute Idee. Die sieht sogar noch besser aus als mein erster 
Gedanke.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Thread beobachten

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

Bestehender Account

oder

Mit Google-Account einloggen

Noch kein Account?

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren