Hallo vielleicht kann mir hier jemand helfen.
Der Compiler erzeugt mir folgende Fehlermeldung:
illegal type combination for '=' (tskTaskControlBlock *volatile, void
*volatile)
In der Doku vom Compiler steht folgende Information dazu:
W2525: illegal type combination for ’operator’ (type1, type2)
The combination of types (type1, type2) for operator operator is not
correct. Type-conversion is executed
and processing continues. This warning message is error message E2524
when the -ansi option is specified.
user0815 schrieb:
> Hallo vielleicht kann mir hier jemand helfen.
Sicherlich.
Da hast einen Fehler im Code.
> Der Compiler erzeugt mir folgende Fehlermeldung:> illegal type combination for '=' (tskTaskControlBlock *volatile, void> *volatile)
Offensichtlich wird hier versucht einem typisierten Pointer ein
void-Pointer zuzuweisen. In C++ ist sowas illegal.
Ob das Problem jetzt mit einem Cast behoben werden kann oder nicht oder
ob es sich hier in Wirklichkeit um ein ganz anderes Problem handelt,
kann man ohne Betrachtung des Codes nicht sagen.
Anscheinend hast du den Wink mit dem Zaunpfahl nicht verstanden:
Zeige deinen Code!(und auch genug aus der Umgebung, wie zb
Datentypdefinitionen, damit man auf dieser Seite des Bildschirms
nachvollziehen kann, was sich der Programmierer dabei gedacht hat obwohl
er es falsch umgesetzt hat)
Also nochmal, der Compiler hat ein Problem mit der Codezeile 1590.
Da scheint der erste Übergabeparameter von der Funktion
"listGET_OWNER_OF_NEXT_ENTRY" Probleme zu bereiten. Weiss allerdings
nicht wo ich da was ändern sollte, damit der Compiler diese Zeile nicht
mehr als Fehler meldet.
> Hallo vielleicht kann mir hier jemand helfen.> Der Compiler erzeugt mir folgende Fehlermeldung:
^^^^^^ Warnmeldung> illegal type combination for '=' (tskTaskControlBlock *volatile, void> *volatile)
listGET_OWNER_OF_NEXT_ENTRY( pxCurrentTCB, &( pxReadyTasksLists[
uxTopReadyPriority ] ) );
// aus tasks.c
PRIVILEGED_DATA tskTCB * volatile pxCurrentTCB = NULL;
PRIVILEGED_DATA static xList pxReadyTasksLists[ configMAX_PRIORITIES ];
/*< Prioritised ready tasks. */
&( pxReadyTasksLists[ uxTopReadyPriority ] ) ist kein void *volatile (
sondern ein PRIVILEGED_DATA static xList * ohne dass ich das jetzt
aufdröseln mag) daher die Warnung beim automatischen Cast in diesen Typ.
Ich würde die Warnung nicht allzu ernst nehmen; bei solchen
Makrospielereien sind die manchmal schwer zu vermeiden.
Zur Frage wie man sie los wird:
- Steht in der Doku vom Compiler auch, welcher Compiler es ist?
Dann wäre die Antwort leichter.
- Außerdem steht in der Doku manchmal
eine Option erwähnt, mit der man den Compiler aufrufen kann,
um gezielt bestimmte Warnungen zu unterdrücken
(z.B. -Woff=2525 oder so ähnlich) oder eine entsprechende
#pragma-Anweisung.
- bist du gewillt, fähig und befugt die list.h zu ändern?
Dann könnte man die letzte Zeile von
1
listGET_OWNER_OF_NEXT_ENTRY(pxTCB,pxList) \
2
{ \
3
xList*constpxConstList=pxList; \
4
/* Increment the index to the next item and return the item, ensuring */ \
5
/* we don't return the marker used at the end of the list. */ \
dann halt mal Doku lesen, wie man die Warnungen beeinflussen kann!
Stichworte: Aufrufparameter und #pragma
Oder im äussersten Notfall verraten, um welches Schmückstück es
sich handelt, falls das nicht top-geheim ist.
das sehe ich, danke.
Leider sagt mir das trotzdem nicht, mit welchem Compiler du das
übersetzen willst.
Und in dessen Doku könnte evtl. stehen, wie man der Warnung
zuleibe rücken kann.
Aber du hast die Doku ja, also bitte lesen.
Die Warnmeldung passt zum CA850, d.h. der ANSI-C compiler package für
NEC V850 Series Targets. In deren FAQ ist auch eine ähnliche Warnmeldung
kommentiert.
http://www.necel.com/cgi-bin/nesdis/o003_e.cgi?article=CA703000
In der Doku steht
http://www.eu.necel.com/_pdf/U17293EJ2V0UM00.PDF
"W2525: illegal type combination for ‘operator’ (type1, type2)
The combination of types (type1, type2) for operator operator is not
correct. Type-conversion is executed and processing continues.
This warning message is error message E2524 when the -ansi option is
specified."
= Exakt das Zitat von "user0815"
Wobei das Beste immer noch wäre, dem Problem nachzugehen.
Da es sich hier ja um eine Datentypwarnung handelt, ist das kein großes
Problem.
Erst mal rausfinden, wo exakt der Compiler warnt.
Dann die exakten Datentpen der beteiligten Operanden feststellen. Das
kann auch bedeuten, dass man einigen Makros nachgehen muss, solange bis
man alles auf die Basisdatentypen heruntergebrochen hat. Dann kann man
weiter entscheiden, wie es weitergeht.
Da es hier aber um einen void Pointer geht, der an einen anderen
Pointertyp zugewiesen werden soll, könnte man zb auch auf den Gedanken
kommen, dass die Compilereinstellungen überprüft werden sollten. Denn
diese Operation ist zwar in C legal, in C++ aber nicht.
Was natürlich nicht heißt, dass auch ein C-Compiler bei so einer
Operation eine Warnung ausgeben darf. DIe Zuweisung eines void Pointers
an einen anderen Pointer-Datentyp ist zwar technisch kein Problem, kann
aber logisch gesehen zu einem Albtraum werden, weil man alleine durch
den void Pointer, ähnlich wie durch einen Cast, alle
Datentypsicherungsmechanismen der Sprache umgeht.
D.h. die eigentliche Frage, der man hier nachgehen sollte, wenn man
gewissenhaft arbeitet, lautet: Warum hat man hier eigentlich einen
void-Pointer? Muss der so sein, oder gibt es Alternativen, diesen void*
loszuwerden.
Ich sehe das Problem an der Stelle im Makro listGET_OWNER_OF_NEXT_ENTRY
(in list.h) bei der dem temporären Pointer pxConstList (Typ xList *
const) das zweite Argumenz pxList (Typ PRIVILEGED_DATA static xList *)
zugewiesen wird.
#define listGET_OWNER_OF_NEXT_ENTRY( pxTCB, pxList ) \
{ \
xList * const pxConstList = pxList; \
...
Wenn ich absolut nicht mit der Warnung leben möchte, dann würde ich als
Gegenmaßnahme dort gemäß FAQ vorgehen
http://www.necel.com/en/faq/mi800/__v85ca.html#0024
Also einen Cast hinzufügen:
xList * const pxConstList = (xList * const) pxList; \
Oder auf die Optimierung ("pxConstList ändert sich nicht!") verzichten
und den Hilfspointer nicht konstant anlegen:
xList * pxConstList = pxList; \
Nachteil: Ich fummele im FreeRTOS Code rum und muss diesen Patch bei
neuen Releases von FreeRTOS nachführen oder ich muss die
Projektverwalter überzeugen den Patch offiziell aufzunehmen.
Ich sehe das Problem ganz woanders:
Der TE will den FreeRTOS-Kram vrmtl. einfach nur verwenden,
aber darin taucht die Warnung auf.
Er wird evtl. weder das durchdringen können noch wollen,
und vorausgesetzt das ist ein Quelltext, der schon mal
gelegentlich getestet wurde und einfach in einem C vor ANSI
geschrieben ist, würde ich die Warnung einfach ignorieren,
solange es keinen Grund gibt, Probleme zu vermuten.
In eigenem Quelltext sehe ich auch zu, ohne Warnungen
kompilieren zu können.
Aber jede übernommene Lib dahin zu bekommen, ist mir zu mühsam.
Zumal in anderer Leute Programme, von denen ich nur Fragmente
bekomme und man dem Frager die Würmer aus der Nase ziehen muß,
bevor er auch nur einen Ton sagt.