Fehlermeldung vom Compiler

[user0815 (Gast)]

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.

[Karl H. (kbuchegg)]

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.

[user0815 (Gast)]

Wie könnte man dies eventuell casten?

[Karl H. (kbuchegg)]

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)

[user0815 (Gast)]

Ich hab mal die C-Datei hier hochgeladen. Die Zeile 1590 macht hier 
Probleme.

Zeile: 1590

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

[Klaus W. (mfgkw)]

Das ist aber nicht 1590.

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

[Klaus W. (mfgkw)]

Vielleicht 1536?

[Klaus W. (mfgkw)]

Da ist aber weit und breit kein =.

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

Vergiß es!

[user0815 (Gast)]

Ok, in der list.h Datei ist die eigentliche Deklaration dieser Funktion 
enthalten.

[user0815 (Gast)]

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.

[Klaus W. (mfgkw)]

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

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

sondern

  #else

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

[user0815 (Gast)]

Der erste Übergabeparameter wird in dieser Headerdatei deklariert.
Dies entspricht einem void-Zeiger.

.globl pxCurrentTCB ; void *

[user0815 (Gast)]

In dieser Funktion macht der Compiler in dieser Zeile Probleme:

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

Tasks.c Datei: Funktion "vTaskSwitchContext"

void vTaskSwitchContext( void )
{
  if( uxSchedulerSuspended != ( unsigned portBASE_TYPE ) pdFALSE )
  {
    /* The scheduler is currently suspended - do not allow a context
    switch. */
    xMissedYield = pdTRUE;
    return;
  }

  traceTASK_SWITCHED_OUT();

  #if ( configGENERATE_RUN_TIME_STATS == 1 )
  {
    unsigned long ulTempCounter = portGET_RUN_TIME_COUNTER_VALUE();

      /* Add the amount of time the task has been running to the accumulated
      time so far.  The time the task started running was stored in
      ulTaskSwitchedInTime.  Note that there is no overflow protection here
      so count values are only valid until the timer overflows.  Generally
      this will be about 1 hour assuming a 1uS timer increment. */
      pxCurrentTCB->ulRunTimeCounter += ( ulTempCounter - ulTaskSwitchedInTime );
      ulTaskSwitchedInTime = ulTempCounter;
  }
  #endif

  taskFIRST_CHECK_FOR_STACK_OVERFLOW();
  taskSECOND_CHECK_FOR_STACK_OVERFLOW();

  /* Find the highest priority queue that contains ready tasks. */
  while( listLIST_IS_EMPTY( &( pxReadyTasksLists[ uxTopReadyPriority ] ) ) )
  {
    --uxTopReadyPriority;
  }

  /* listGET_OWNER_OF_NEXT_ENTRY walks through the list, so the tasks of the
  same priority get an equal share of the processor time. */
  listGET_OWNER_OF_NEXT_ENTRY( pxCurrentTCB, &( pxReadyTasksLists[ uxTopReadyPriority ] ) );

  traceTASK_SWITCHED_IN();
  vWriteTraceToBuffer();
}

[user0815 (Gast)]

Entschuldige vielmals Klaus. Ich hab mich da vertan. Ich meine die Zeile 
1536.

[Stefan B. (stefan)]

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

[user0815 (Gast)]

Kann ich die Warung vernachlässigen?
Wie könnte ich dafür sorgen, dass womöglich die Warnung nicht wieder 
erscheint?

[Klaus W. (mfgkw)]

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

listGET_OWNER_OF_NEXT_ENTRY( pxTCB, pxList )                  \
{                                            \
xList * const pxConstList = pxList;                            \
  /* Increment the index to the next item and return the item, ensuring */      \
  /* we don't return the marker used at the end of the list.  */            \
  ( pxConstList )->pxIndex = ( pxConstList )->pxIndex->pxNext;            \
  if( ( pxConstList )->pxIndex == ( xListItem * ) &( ( pxConstList )->xListEnd ) )  \
  {                                          \
    ( pxConstList )->pxIndex = ( pxConstList )->pxIndex->pxNext;          \
  }                                          \
  pxTCB = ( pxConstList )->pxIndex->pvOwner;                      \

ändern zu:

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

Ich vermute, daß die Warnung dann weg ist.

[user0815 (Gast)]

Danke Klaus, leider erscheint bei mir da die gleiche Warnung.

[Klaus W. (mfgkw)]

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.

[Stefan B. (stefan)]

Das ist Quellcode von FreeRTOS

[Klaus W. (mfgkw)]

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.

[Stefan B. (stefan)]

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"

[Klaus W. (mfgkw)]

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.

[Karl H. (kbuchegg)]

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.

[Karl H. (kbuchegg)]

Versuchs mal so

  /* Find the highest priority queue that contains ready tasks. */
  while( listLIST_IS_EMPTY( &( pxReadyTasksLists[ uxTopReadyPriority ] ) ) )
  {
    --uxTopReadyPriority;
  }

  /* listGET_OWNER_OF_NEXT_ENTRY walks through the list, so the tasks of the
  same priority get an equal share of the processor time. */
  listGET_OWNER_OF_NEXT_ENTRY( (void*)pxCurrentTCB, &( pxReadyTasksLists[ uxTopReadyPriority ] ) );

[Stefan B. (stefan)]

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.

[Klaus W. (mfgkw)]

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.