C-verständnisproblem

[Felix (Gast)]

mahlzeit,
ich habe ein Problem beim Verständis eines Fehlers.
ich habe folgende sachen:

typedef struct
{
    uint8    messageType;
    uint8    messageSubType;  
    uint16   messagesize;
} message __attribute__((aligned(4)));

typedef struct
{
    uint8   ecuNumber;                   
    uint16  aliveTime;                  
    uint16  sizeReqponseTable;      
    uint16  sizeRequestTable;       
    uint32  *requestTable;          
    uint32  *responseTable;          
    uint16  sizeReqponseTable;      
    uint16  sizeRequestTable;           
} commInit;


static void function()
{
..
  message *msg_p

  msg_p = (message *) getData(msg);

  commInit *init_p = (commInit*)&msp_p[1];

static uint32 responseTable_au32[200];
static uint32 requestTable_au32[200];

static void init()
{
...
  commInit init;
  ...
  init.responseTable = responseTable_au32;
  init.requestTable = requestTable_au32;
...

Der Fehler tritt bei
commInit *init_p = (commInit*)&msp_p[1];
auf.

bei der Initialisierung
  init.responseTable = responseTable_au32;
  init.requestTable = requestTable_au32;
seht in init.responseTable und init.requestTable die adresse von 
responseTable_au32 und requestTable_au32 (32 bit-Adressen).

was genau steht in &msp_p[1] ?
msp_p ist doch nur ein pointer auf eine Struktur. aber was genau bewirkt 
[1] ?

Das Problem bei
commInit *init_p = (commInit*)&msp_p[1];
ist, dass danach in init_p->responseTable_au32 und in 
init_p->requestTable_au32 eine andere Adresse steht. Es die Adresse wie 
responseTable_au32 und requestTable_au32 aber als 64 bit-Adresse (mit 0 
aufgefüllt)

Beispiel Adresse von responseTable_au32 is 0x23232323
Bei der Initialisierung steht in init.responseTable ebenfalls 0x23232323
in init_p-responseTable steht jetzt allerdings 0x2323232300000000
Wenn ich jetzt darein schreiben möchte, kracht es natürlich.

Der Code kommt von einem 32-bit system. Jetzt bauen wir aber in einem 
64-bit system. kann es daran liegen? Dann hätte ich aber gedacht, dass 
responseTable_au32 ebenfalls schon eine 64 Bit-Adresse hat.

Wie kann ich das Problem fixen? Am Code selber dürfen wir leider nichts 
ändern (es sei denn es muss, so wie in diesem Fall)

[mh (Gast)]

Das sieht dem Thread Beitrag "Probleme bei Pointer in C. Code crasht" 
irgendwie ziemlich ähnlich.

[sid (Gast)]

Felix schrieb:
> typedef struct
> {
>     uint8   ecuNumber;
>     uint16  aliveTime;
>     uint16  sizeReqponseTable;
>     uint16  sizeRequestTable;
>     uint32  *requestTable;
>     uint32  *responseTable;
>     uint16  sizeReqponseTable;
>     uint16  sizeRequestTable;
> } commInit;
sizeReqponseTable und sizeRequestTable scheinen mir doch sehr redundant 
;)

entferne je einen davon und teste nochmal

'sid

[mh (Gast)]

sid schrieb:
> entferne je einen davon und teste nochmal

Was genau soll das ändern? Stehen die in Zeile 42?

[Nick M. (Gast)]

Lass doch mal die dämliche Casterei weg. Die sollte man nur in wirklich 
begründeten Ausnahmefällen verwenden.
Ansonsten verhindert das nur Meckerei vom Compiler (und ich hab keine 
Lust so einen Müll zu lesen).

[Jay Low (Gast)]

Naja theoretisch könnten sie unterschiedlich gross sein. Oder übersehe 
ich etwas?

arg Jetzt sehe ich es auch... Gehen Sie weiter es gibt nichts zu 
sehen!

Ich glaube zu verstehen, um was es prinzipiell geht: Ein 
Request/Response Protokoll mit einer Queue.

Aber dann hört es auf. Wie stehen die beiden Strukturen 'message' und 
'commInit' im Zusammenhang?
Sollen 'message' in die Tabellen geschrieben werden? Dann ist der Typ 
doch falsch.

static message *responseTable_au32[200];
static message *requestTable_au32[200];

Und dann das hier:

 
message *msg_p
msg_p = (message *) getData(msg);
commInit *init_p = (commInit*)&msp_p[1];

Ich vermute 'getData()' liest eine Message von der Gegenstelle und gibt 
einen Pointer auf diese Message aus (wegen dem Cast).
Was macht dann diese komische Zuweisung mit den noch viel obskureren 
Casts?!
Wenn man Vermutung stimmt würde ich eher sowas erwarten:

init_p->requestTable[init_p->sizeRequestTable++] = msp_p;

Eventuell ist das aber auch alles nur Mist, was ich hier schreibe.

[sid (Gast)]

mh schrieb:
> Stehen die in Zeile 42?
ich glaub die Frage muss neu gestellt werden ;)

Sollten zwei Variablen einer struct gleich benannt sein,
welche wird gesetzt/gelesen beim Aufruf?
(ja fast alle compiler löschen die selbst... aber ist das guter Stil es 
überhaupt zu versuchen?)

Eben.

int64 in int16 zu quetschen und zwischendrin eine int 32 als 
Transportvehikel zu nutzen kann ja nur Fehler verursachen
wenn irgendein Wert grösser als 16bit ist.

Ich selbst würde da jetzt die Grössen abhängig von der Targetarchitektur
machen.
sodass ich eben nicht in einer 16bit variable einen 64bit wert versuche 
zu lesen
(es sei denn er ist zu jeder Zeit ein 16bit variable mit 2^48 
multipliziert... aber wann kann man sich darauf schon verlassen?)

Aber ehrlich gesagt fand ich den Teil der Frage viel weniger 
Interessant,
als das ignorieren der Warnmeldung beim compilieren wegen der struct.
(da sollte mMn eine kommen)
deswegen hab ich mich auch nur dazu geäussert ;)

'sid

PS Maus ist raus

[mh (Gast)]

sid schrieb:
> mh schrieb:
>> Stehen die in Zeile 42?
> ich glaub die Frage muss neu gestellt werden ;)
>
> Sollten zwei Variablen einer struct gleich benannt sein,
> welche wird gesetzt/gelesen beim Aufruf?

Es ist allerdings sehr fraglich, dass der eigentliche Quelltext, der 
diesen "Fehler" hat, mit dem übereinstimmt, was hier gepostet wurde.

Ich zitiere Yalu X. aus dem oben von mir verlinkten Thread. Er hat es 
ganz gut zusammengefasst.

Die Anfrage mutet ein wenig wie folgende Aufgabe an:

Setze den unvollständigen Haufen einzelner Scherben zur ursprünglichen
Vase zusammen und finde anschließend die Undichtigkeit in derselben ;-)

[Mark B. (markbrandis)]

Felix schrieb:
> mahlzeit,
> ich habe ein Problem beim Verständis eines Fehlers.

Dann sei doch bitte so gut und poste den Quellcode als Datei im Anhang. 
Und zwar gerade so viel, wie nötig ist damit der Code a) sich 
kompilieren lässt und b) der Fehler reproduzierbar ist.