Frage zur Speicherverwaltung mittels struct

brechbunkt Gast #2896930
Lesenswert?
• ▲
▼ 
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.

1
typedef struct

2
{

3
    unsigned short bfType;

4
    unsigned int   bfSize;

5
    unsigned short bfReserved1;

6
    unsigned short bfReserved2;

7
    unsigned int   bfOffBits;

8
} 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.
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
(prx) A. K. #2896951
Lesenswert?
• ▲
▼ 
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.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Johann L. Persönliche Seite #2896977
Lesenswert?
• ▲
▼ 
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:

1
typedef struct

2
{

3
    unsigned int   bfSize;

4
    unsigned int   bfOffBits;

5
    unsigned short bfType;

6
    unsigned short bfReserved1;

7
    unsigned short bfReserved2;

8
} myStruc_t;
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Hmm Gast #2896984
Lesenswert?
• ▲
▼ 
>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.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Udo S. #2896997
Lesenswert?
• ▲
▼ 
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.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Thread beobachten

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

Bestehender Account

oder

Mit Google-Account einloggen

Noch kein Account?

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren