Frage zur Speicherverwaltung mittels struct

[brechbunkt (Gast)]

Hallo,

ich habe die nachfolgende Struktur und mir ist wichtig, dass die 
Variablen dann auch tatsächlich genau so im Speicher angeordnet werden.

Richtiger weise schreibt meine 32-Bit-CPU die erste Variable (bfType) ab 
Adresse "Null". Diese Zahl ist dann 2 Byte lang.
Was ich nicht möchte ist, dass sie die nächsten 2 Byte einfach links 
liegen lässt (was aber der Fall ist).
Erst die danach folgenden 4 Bytes bekommen Werte meiner Variable bfSize 
zugewiesen.

typedef struct
{
    unsigned short bfType;
    unsigned int   bfSize;
    unsigned short bfReserved1;
    unsigned short bfReserved2;
    unsigned int   bfOffBits;
} myStruc_t;

Gibt es eine Möglichkeit die CPU (bzw. den compiler) dazu zu zwingen, 
dass er meine zweite Variable (bfSize) auf jedem Fall an der dritten 
Byteadresse speichern muss?
Bitfelder zu definieren bringt ja auch nichts, da die vom compiler 
angeordnet werden dürfen wie er möchte.

[Oliver J. (skriptkiddy)]

gcc:

__attribute__ ((__packed__))

Beachte aber das Alignment. Bei einem ARM-Prozessor bekommst du damit 
unter Umständen Probleme.

Gruß Oliver

[(prx) A. K. (prx)]

Oliver J. schrieb:
> Beachte aber das Alignment. Bei einem ARM-Prozessor bekommst du damit
> unter Umständen Probleme.

Funktionieren wird es bei direkten Zugriffen, da der Compiler um das 
falsche Alignment weiss. Alignment-Probleme entstehen dort, wo er es 
nicht weiss (Pointer).

Problemlos:
  return s.bfSize;
Problem:
  unsigned *p = &s.bfSize; // keine(!) Warnung
  return *p; // je nach Core kann das in die Hose gehen

PS: Bezieht sich auf GCC mit "packed". Portabel ist so etwas nicht. Mit 
Bitfeldern vermeidet man immerhin den Problemfall.

[Johann L. (gjlayde)]

Bitfelder bringen u.U. aber ganz andere Probleme, insbesondere wenn 
irgendwo ein volatile in der Nähe ist...

Falls du selbst das struct-Layout festlegst (sieht bei dem Layout ganz 
danach aus), dann mach das so, daß es keine Lücken gibt.  Beispiel:

typedef struct
{
    unsigned int   bfSize;
    unsigned int   bfOffBits;
    unsigned short bfType;
    unsigned short bfReserved1;
    unsigned short bfReserved2;
} myStruc_t;

[Hmm (Gast)]

>Bitfelder bringen u.U. aber ganz andere Probleme, insbesondere wenn
irgendwo ein volatile in der Nähe ist...

Magst Du das mal ein wenig näher beleuchten, Johann? Ich bin sicher das 
interessiert viele.

[(prx) A. K. (prx)]

Siehe http://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html unter 
-fstrict-volatile-bitfields. Wobei das ein recht heiss diskutiertes 
Thema zu sein scheint. Wär wohl besser, sich in der Frage volatiler 
Bitfelder nicht zu sehr auf den Compiler zu verlassen.

[Udo S. (urschmitt)]

Normalerweise hat man ein falsches Design, wenn man meint solche 
absoluten Adresspositionen zu brauchen.
Im Zweifel kann man noch 'padding' Variablen einfügen, die sicher dafür 
sorgen, daß die wichtigen Variablen fest auf durch 2/4/8 teilbaren 
Adressen beginnen.
Im allgemeinen sind solche Konstruktionen aber Scheiße, da sollte man 
lieber mal die Performance-Keule im Schrank lassen und eine 
Konvertierungsfunktion schreiben.

[brechbunkt (Gast)]

Oliver J. schrieb:
> gcc:__attribute__ ((_packed_))
>
> Beachte aber das Alignment. Bei einem ARM-Prozessor bekommst du damit
> unter Umständen Probleme.
>
> Gruß Oliver

Ich danke sehr für die Antworten. Der Hinweis vom Oliver war super, 
jetzt funktioniert es.