Fehlermeldung vom Compiler

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)

Das ist aber nicht 1590.

Und der Quelltext ist so grottig, daß ich nicht darin suchen will.

Vielleicht 1536?

Da ist aber weit und breit kein =.

Außerdem hilft die .c nichts, wenn man die Deklarationen nicht hat.

Vergiß es!

und nochmal: in dem Quelltext von dir steht in Zeile 1590 nicht

1

listGET_OWNER_OF_NEXT_ENTRY( pxCurrentTCB, &( pxReadyTasksLists[ uxTopReadyPriority ] ) );

sondern

1

  #else

Aber mir egal, ich mache mir jetzt was leckeres zu Essen.
Viel Spaß beim Suchen!

> 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 * const pxConstList = 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.  */            \

6

  ( pxConstList )->pxIndex = ( pxConstList )->pxIndex->pxNext;            \

7

  if( ( pxConstList )->pxIndex == ( xListItem * ) &( ( pxConstList )->xListEnd ) )  \

8

  {                                          \

9

    ( pxConstList )->pxIndex = ( pxConstList )->pxIndex->pxNext;          \

10

  }                                          \

11

  pxTCB = ( pxConstList )->pxIndex->pvOwner;                      \

ändern zu:

1

  pxTCB = (void*)( ( pxConstList )->pxIndex->pvOwner );

Ich vermute, daß die Warnung dann weg ist.

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 ist Quellcode von FreeRTOS

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"

ich verstehe nur nicht, warum ER das nicht verrät.
Alle Leute dürfen raten, worüber er stolpert, und für ihn googeln.
Naja, es klappt ja.

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.

Versuchs mal so

1

  /* Find the highest priority queue that contains ready tasks. */

2

  while( listLIST_IS_EMPTY( &( pxReadyTasksLists[ uxTopReadyPriority ] ) ) )

3

  {

4

    --uxTopReadyPriority;

5

  }

6

7

  /* listGET_OWNER_OF_NEXT_ENTRY walks through the list, so the tasks of the

8

  same priority get an equal share of the processor time. */

9

  listGET_OWNER_OF_NEXT_ENTRY( (void*)pxCurrentTCB, &( pxReadyTasksLists[ uxTopReadyPriority ] ) );

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.