packed struct/union in C und C++

1

struct frame_T

2

{

3

    class_t     *class_ptr;

4

    value_t      locals[1];

5

...

ein Array der Länge 1?
Ich wittere da einen Array-Overflow.

Wozu ist hier die Packerei gut? Bei diesen Datentypen brennt auch ohne 
nichts an.

Karl Heinz Buchegger schrieb:
> ein Array der Länge 1?

Möglicherweise soll das ein "flexible array member" sein, wobei man
diese seit C99 ohne Größenangabe schreibt, also

1

struct frame_T

2

{

3

    class_t     *class_ptr;

4

    value_t      locals[];

5

};

Egal ob mit oder ohne Größenangabe, in C++ sind solche Dinge m.W.
offiziell nicht vorgesehen (höchstens vielleicht in C++11), könnten aber
trotzdem funktionieren. Ganz sicher kann man aber solche Strukturen
nicht mit new anlegen, da man dort im Gegensatz zu malloc keine
Größe übergibt, die ja in diesem Fall variabel ist.

Vielleicht liegt also der Fehler darin, dass für die Strukturen zu wenig
Speicher reserviert wird.

Welche Absicht aber tatsächlich hinter der [1] steckt, das kann uns nur
Fabian sagen.

Fabian schrieb:
> Die Struktur sowie die Union wurde mit #pragma pack(2) versehen, da
> diese typen mit dem alignment in einem file übereinstimmen müssen

Was soll das, mach ordentliche read und write Funktionen, dann muss gar 
nichts übereinstimmen und es ist portabel.

Fabian schrieb:
> und wird einerseits über bestehende Daten im Flash "gestülpt"

Dasselbe wie oben, das ist Trickprogrammierung. Kann man machen wenn das 
genau für eine Anwendung und einen Prozessor gemacht wird, aber beim 
Portieren immer eine Lotterie.
Wenn man hier nicht unbedingt das letzte halbe Prozent an Performance 
braucht, macht man sowas mit sauberen Konvertierfunktionen.

Meine Meinung!

Fabian schrieb:
> Warum die ganze packerei? Dies hat schon seinen Grund, denn der struct
> ist eigentlich deutlich grösser (dies ist nur das Ende davon...)

Ahnte ich es doch... Information hiding an entscheidender Stelle. Na 
dann such mal schön.

Fabian schrieb:
> Gewisse Leute in diesem Forum werden, sofern sie nicht gerade eine
> Lösung bereit haben, seeehr schnell persönlich.
??
Falls mein Beitrag gemeint sein sollte, erklärs mir.

Fabian schrieb:
> Naja, dann poste ich das nächste mal den ganzen Source Code...

Die ganze Struktur wär schon mal ein Ansatz. Denn in der gezeigten 
Struktur ist kein Anlass für einen einzelnen Bytezugriff zu sehen. Aber 
generell gilt es, bei Suche nach hartnäckigen Fehlern das Programm auf 
das Minimum abzuspecken, in dem das Problem immer noch auftritt. Das 
hilft nicht nur beim Posten vom Code, sondern auch dir.

Ausserdem solltest du deinen Code mal auf Stellen untersuchen, in denen 
die Adresse eines misaligned members verwendet wird, statt direkt darauf 
zuzugreifen. Ich weiss nicht wie IAR sich in diesem Fall verhält, aber 
bei GCC kann das grandios und ohne Warnung in die Hose gehen.

> seeehr schnell persönlich

Persönlich geht anders. Allerdings nervt es auf Dauer, wenn immer wieder 
Leute zielsicher genau jene Teile posten, die ziemlich wahrscheinlich 
nicht die Ursache des Problem sind (noch nerviger ist allerdings 
abgetippter Code der Marke "so ähnlich, nur ohne die ganzen Tipp- und 
Syntaxfehler").