Offset eines Struktur-Elements bestimmen ohne vorhandene Variable

[Wastl (hartundweichware)]

Problem: in einem kleinen RAM sollen stückweise EEPROM-Elemente
gelesen/geschrieben werden. Die Struktur des EEPROMs ist grösser
als das was im RAM gehalten werden kann. Somit ergibt sich das
Problem den Offset eines Struktur-Elements zu bestimmen ohne
eine komplette Instanz einer Struktur angelegt zu haben.

Soweit ich aus Suchanfragen entnommen habe funktioniert
<offsetof> nur mit Bezug auf eine existierende Struktur - so
werden die Beispiele formuliert. Ich würde aber gerne die
Funktionalität von <offsetof> auf eine Struktur-Definition
bezogen, also nicht auf eine existierende Struktur haben.

Wie geht das bitte?
(hier im Code ohne Anwendung von <offsetof>)

void struct_test (void)
{
  uint32_t offsC;  // zu berechnender Offset

  typedef struct  // Struktur Definition
  {
    uint16_t  varA;
    uint32_t  varB;
    uint8_t   varC;
  } mystruct_def;

  mystruct_def  sample;  // eine Instanz der Struktur

  // so geht's z.B. mit angelegter Struktur-Variable
  offsC = (uint8_t*)&sample.varC - (uint8_t*)&sample.varA;

  //offsC = (uint8_t*)&mystruct_def.varC - (uint8_t*)&mystruct_def.varA;
  // geht nicht da <mystruct_def> keine Variable im Speicher ist

} /* --- struct_test ---*/

[Oliver S. (oliverso)]

Das C-Makro offsetof() benötigt den Typ, keine Instanz. Das reicht für 
den Compiler ja völlig aus, die offsets zu berechnen.

Oliver

[Wastl (hartundweichware)]

Oliver S. schrieb:
> Das C-Makro offsetof() benötigt den Typ, keine Instanz. Das reicht für
> den Compiler ja völlig aus, die offsets zu berechnen.

Dann schreibe doch bitte eine funktionierende Zeile hin die
zu meinem Beispiel-Code passt.

Ich habe nur Beispiele gesehen in denen das Argument von <offsetof>
eine existierende Struktur ist, keine Struktur-Definition.

[Wastl (hartundweichware)]

Ich denke ich hab es gerade selbst gefunden. Der Gedanke
kommt beim Reden ....

void struct_test (void)
{
  uint32_t offsC;  // zu berechnender Offset

  typedef struct  // Struktur Definition
  {
    uint16_t  varA;
    uint32_t  varB;
    uint8_t   varC;
  } mystruct_def;

  offsC = offsetof(mystruct_def, varC);

} /* --- struct_test ---*/

[Wastl (hartundweichware)]

Wastl schrieb:
> Ich denke ich hab es gerade selbst gefunden.

Funktioniert leider nicht bei ineinandergeschachtelten
Structs. Es sei denn ich habe noch nicht herausgefunden wie
man das formuliert ....

[Dergute W. (derguteweka)]

Moin,

Ich wuerde mal vermuten, dass du dann auch die offsetoffs schachteln 
musst und dann deren Ergebnisse addieren.

Gruss
WK

[Wastl (hartundweichware)]

Dergute W. schrieb:
> Ich wuerde mal vermuten, dass du dann auch die offsetoffs schachteln
> musst

Ich befürchte so etwas in der Richtung.

[Daniel A. (daniel-a)]

Wastl schrieb:
> Wastl schrieb:
>> Ich denke ich hab es gerade selbst gefunden.
>
> Funktioniert leider nicht bei ineinandergeschachtelten
> Structs.

Klar geht das.

void struct_test (void)
{
  uint32_t offsB;  // zu berechnender Offset
  typedef struct  // Struktur Definition
  {
    uint16_t  varA;
    struct {
      uint32_t  varB;
    } verschachtelt;
    uint8_t   varC;
  } mystruct_def;
  offsB = offsetof(mystruct_def, verschachtelt.varB);
} /* --- struct_test ---*/

[Wastl (hartundweichware)]

Daniel A. schrieb:
> Klar geht das.

Stimmt, jetzt wo du es schreibst .... Danke für den Schubser ...

Hier ein Beispiel in meiner Ausführung mit separat
definierter Struktur und Sub-Struktur.

uint32_t calc_offs (void)
{
  uint32_t offs_val;  // zu berechnender Offset

  typedef struct  // untergeordnete Struktur Definition
  {
    uint32_t  varA;
    uint16_t  varB;
    uint8_t   varC;
  } smallstruct_def;

  typedef struct  // uebergeordnete Struktur Definition
  {
    smallstruct_def  smallA;
    smallstruct_def  smallB;
    smallstruct_def  smallC;
  } top_struct_def;

  offs_val = offsetof(top_struct_def, smallB.varC);

  return offs_val;

} /* --- calc_offs ---*/

[Apollo M. (Firma: @home) (majortom)]

Wastl schrieb:
> Somit ergibt sich das
> Problem den Offset eines Struktur-Elements zu bestimmen

Warum der Offset gebraucht werden soll, erschließt sich nicht aus der 
Problembeschreibung. Wenn du mal das Pronlemm besser beschreibst , dann 
zeige ich, wie das OHNE den Offset geht. Hier wird nur rumgespielt mit 
struct anstatt mit Sinn verwendet.

... vom smallstruct_def anstatt smallstruct_t bekommt man 
Bauchschmerzen!

Also zeige Beispiele wie du den offsetof() Wert verwenden willst ...

[Wastl (hartundweichware)]

Apollo M. schrieb:
> ... vom smallstruct_def anstatt smallstruct_t bekommt man
> Bauchschmerzen!

Ok, ich tu dir was Gutes und verwende in Zukunft in der
Öffentlichkeit und privat immer *_t Strukturdefinitionen
anstat von *_def. Das kann ich nicht verantworten dass du
im Anblick meiner Veröffentlichungen Bauchschmerzen bekommst.

Apollo M. schrieb:
> Warum der Offset gebraucht werden soll, erschließt sich nicht aus der
> Problembeschreibung.

Im Übrigen hat keiner Derjenigen die sich zu Wort gemeldet
haben eine Frage nach dem Sinn meines Tuns gestellt. Damit
nehme ich an dass es bisher alle verstanden haben und auch
einen Sinn darin erkannt haben.

Weitere Auführungen erspare ich mir, ich kann jetzt genau das
machen was ich vorhabe.

[Apollo M. (Firma: @home) (majortom)]

Wastl schrieb:
> Im Übrigen hat keiner Derjenigen die sich zu Wort gemeldet
> haben eine Frage nach dem Sinn meines Tuns gestellt. Damit
> nehme ich an dass es bisher alle verstanden haben und auch
> einen Sinn darin erkannt haben.

Aua, das tut weh!

Wenn du glücklich bist, weil du denkst alles zu können, dann ist alles 
perfekt!

Sehr überzeugend zu denken, dass zwei pro und eine contra Wortmeldung 
eine sichere Selbstbestätigung sind.

[Max H. (nilsp)]

Wastl schrieb:
> Ok, ich tu dir was Gutes und verwende in Zukunft in der
> Öffentlichkeit und privat immer *_t Strukturdefinitionen
> anstat von *_def.

Mep, nicht machen.

Alle _t Typen sind für Posix reserviert. Wenn Du selbst einen Typ mit _t 
anlegst riskierst Du bei jedem Standard Update einen Typenkonflikt.

Das betrifft noch ein paar andere Namen. GCC hat netterweise eine Liste: 
https://www.gnu.org/software/libc/manual/html_node/Reserved-Names.html

[Bruno V. (bruno_v)]

Apollo M. schrieb:
> Aua, das tut weh

Apollo, der TO hat ein typisches Problem, dass auch erfahrene 
Programmierer mit offsetof lösen und zur ersten Verwendung eine Frage, 
die schnell und sachlich beantwortet wurde

Jetzt kommst Du, mäkelst an seinen Bezeichnern und versprichst eine 
alternative Lösung, wenn er sich komplett auszieht.

Vermutlich wird Deine Lösung nur dann funktionieren, wenn er die 
Programmiersprache wechselt, die Architektur umschmeißt oder 2 
Statements da nutz, wo vorher eines war.

Wenn Du eine anfängertaugliche alternative zu offsetof kennst, in plain 
C, für den Anwendungsfall hier (einzelne Elemente im eeprom spiegeln, 
dann sttelle das in deinem Thread vor oder ins Wiki.

[Oliver S. (oliverso)]

Wastl schrieb:
> Im Übrigen hat keiner Derjenigen die sich zu Wort gemeldet
> haben eine Frage nach dem Sinn meines Tuns gestellt. Damit
> nehme ich an dass es bisher alle verstanden haben und auch
> einen Sinn darin erkannt haben.

Nein, aber den Kommentar, daß deine nur sehr rudimentären C-Kentnisse 
auch darauf schließen lassen, daß du da nach einer Lösung für ein 
klassisches xy-Problem suchst, hatte ich mir verkniffen. Aber bitte, 
wurde nachgeliefert.

Oliver

[Johann L. (gjlayde)]

Wastl schrieb:
> Problem: in einem kleinen RAM sollen stückweise EEPROM-Elemente
> gelesen/geschrieben werden. Die Struktur des EEPROMs ist grösser
> als das was im RAM gehalten werden kann.

Ich muss gestehen, dass ich das Problem auch nicht wirklich verstehe,

> void struct_test (void)
> {
>   ...
> 
>   typedef struct  // Struktur Definition
>   {
>     uint16_t  varA;
>     uint32_t  varB;
>     uint8_t   varC;
>   } mystruct_def;

Wenn die Struktur für's RAM zu groß ist, warum dann alles mögliche reinstopfen? Man kann doch

[c]
#include <avr/eeprom.h>

typeA_t varA EEMEM;
typeB_t varB EEMEM;
typeC_t varC EEMEM;
...

und die dann einlesen?

Oder, wenn man gerne einen Struct darum hat, auf die Komponenten 
zugreifen so wie man's braucht?

#include <avr/eeprom.h>

typedef ... typeA_t;
typedef ... typeB_t;

typedef struct
{
    typeA_t varA;
    typeB_t varB;
} eeprom_t;

// Als extern in *.h
eeprom_t eeprom EEMEM;

typeA_t varA;
typeB_t varB;

int main (void)
{
    eeprom_read_block (&varA, &eeprom.varA, sizeof (varA));
    eeprom_read_block (&varB, &eeprom.varB, sizeof (typeB_t));
    return 0;
}

Beim Zugriff hat man die entsprechenden Objekte doch zur Hand.

[Le X. (lex_91)]

Johann L. schrieb:
> Ich muss gestehen, dass ich das Problem auch nicht wirklich verstehe,

in deiner Lösung gehst du aber davon aus dass es sich a) um einen Atmel 
handelt und b) die Verwendung von eeprom.h gewünscht ist.

Ich muss gestehen, ich verstehe die Frage des TE und halte das Vorgehen 
für sinnvoll.
Du kannst dir dein Eeprom-Layout einfach per typedef struct vom Compiler 
erzeugen lassen und dir mit offsetof die Adressen für die read- und 
write-Funktionen berechnen lassen.
Dazu braucht es keine Instanz im RAM.

[Le X. (lex_91)]

Apollo M. schrieb:
> Warum der Offset gebraucht werden soll, erschließt sich nicht aus der
> Problembeschreibung. Wenn du mal das Pronlemm besser beschreibst , dann
> zeige ich, wie das OHNE den Offset geht. Hier wird nur rumgespielt mit
> struct anstatt mit Sinn verwendet.

gähn

Der Nachste der meint, besser zu wissen was der TE braucht und was 
nicht.

Ich verstehe seine Frage, seinen Lösungsansatz und kann bezeugen dass 
dieser Ansatz durchaus auch im Professionellem eingesetzt wird.
Folgere doch bitte von deinem Horizont nicht auf Andere.

[Johann L. (gjlayde)]

Le X. schrieb:
> Johann L. schrieb:
>> Ich muss gestehen, dass ich das Problem auch nicht wirklich verstehe,
>
> in deiner Lösung gehst du aber davon aus dass es sich a) um einen Atmel
> handelt und b) die Verwendung von eeprom.h gewünscht ist.

Das wird verwendet zum Lokatieren im EEprom und zum Zugriff; ist jetzt 
nicht sooo exotisch.

> Du kannst dir dein Eeprom-Layout einfach per typedef struct vom Compiler
> erzeugen lassen und dir mit offsetof die Adressen für die read- und
> write-Funktionen berechnen lassen.

In meinem Beispiel (Teil2) wird das EEprom auch als Struct modelliert.

Um sich die Adresse z.B. einer Komponente des Structs zu besorgen gibt's 
doch den &-Operator in C/C++, und wieviel Bytes zu lesen sind erhält man 
mit sizeof.

> Dazu braucht es keine Instanz im RAM.

In meinem Beispiel auch nicht.  Das Beispiel zeigt nur die Verwendung. 
Um die Adressen und Größen der Komponenten zu erhalten genügt der 
Typedef für den Struct und (eine externe Referenz) auf das EEprom 
Object.

Und die Adresse des EEprom-Objects braucht mam mit sizeof ja auch.  (und 
wenn man die Adresse als 0x0 hart codiert, brauch man auch im meinem 
Beispiel KEINE Referenz des Objects).

[Bruno V. (bruno_v)]

Johann L. schrieb:
> Um sich die Adresse z.B. einer Komponente des Structs zu besorgen gibt's
> doch den &-Operator in C/C++, und wieviel Bytes zu lesen sind erhält man
> mit sizeof.

Der TO ist ein Anfänger, der das Define für offsetof nicht kannte und 
auch nicht den Cast des Nullpointers zur Adressbestimmung.

Mit 100%iger Sicherheit ist sein Code nicht optimal. Ja und? Er hat 
jetzt einen Ansatz mit dem er arbeiten und Erfahrungen sammeln kann.

Wenn ich ein fremdes Auto erstmals fahre, möchte ich nicht noch, dass 
jemand zuschaut und Tips gibt.

Hier haben wir einen Fahranfänger mit 100 Experten (Mitleser) auf dem 
Beifahrersitz, die sehen wollen, ob er früh genug blinkt. Ohne dass ein 
Crash uns den Versicherungsrabatt kostet.

Lassen wir Compiler und HW zeigen, ob er richtig fährt. Er kann 
jederzeit fragen, wenn er dauernd  crashed.

[Hannes J. (Firma: _⌨_) (pnuebergang)]

Wenn man seine Sachen sauber definiert gibt es keinen Grund für 
offsetof(). Welches im Prinzip sowieso nur mit Pointern spielt. Je nach 
Compiler etwas grenzwertig mit einem Null-Pointer.

Wenn man voraus denkt:

Man legt die gemeinsamen Daten einfach an den Anfang, d.h. Offest 0.

// Data that happens to be stored in RAM or EEPROM
typedef struct {
    int com1;
    int com2;
} common_data;

// Data that happens to be stored in EEPROM
typedef struct {
    common_data common;
    int ep1;
    int ep2;
} eeprom_data;

common_data ram_destination;
// Ignore details of eeprom access mechanisms for demonstration purposes
eeprom_data *eeprom_source = <eeprom source address>;
copy_from_eeprom_to_ram(&ram_destination, eeprom_source, sizeof(common_data));

Man muss halt vorher nur mal für fünf Cent nachdenken wie man seine 
Datenstruktur ins EEPROM legen möchte.

Man kann das ganze auch noch komplizierter machen wenn man es 
symmetrischer haben möchte:

// Data that happens to be stored in RAM or EEPROM
typedef struct {
    int com1;
    int com2;
} common_data;

// Data stored in RAM
typedef struct {
    common_data common;
} ram_data;

// Data that happens to be stored in EEPROM
typedef struct {
    common_data common;
    int ep1;
    int ep2;
} eeprom_data;

Und wenn man es doch versaut hat:

// Data that happens to be stored in RAM or EEPROM
typedef struct {
    int com1;
    int com2;
} common_data;

// Data that happens to be stored in EEPROM
// screwed-up layout
typedef struct {
    int ep1;
    common_data common;
    int ep2;
} eeprom_data;

common_data ram_destination;
// Ignore details of eeprom access mechanisms for demonstration purposes
eeprom_data *eeprom_source = <eeprom source address>;

copy_from_eeprom_to_ram(&ram_destination, &(eeprom_source->common), sizeof(common_data));

Ach ja, alles unter der Annahme man hat das Allignment im Griff.

[Rolf M. (rmagnus)]

Hannes J. schrieb:
> Wenn man seine Sachen sauber definiert gibt es keinen Grund für
> offsetof(). Welches im Prinzip sowieso nur mit Pointern spielt. Je nach
> Compiler etwas grenzwertig mit einem Null-Pointer.

Nein, da ist nichts grenzwertig. offsetof() ist ein Standard-Makro. Wie 
der Compiler das umsetzt, ist seine Sache, aber es muss entsprechend der 
Spezifikation funktionieren.

[Le X. (lex_91)]

Hannes J. schrieb:
> Man muss halt vorher nur mal für fünf Cent nachdenken wie man seine
> Datenstruktur ins EEPROM legen möchte.

Und wie kommt man dann darauf, zwei typedefs zu verwenden?
Kein Vorteil, aber doppelter Pflegeaufwand und fehleranfällig.

[Bruno V. (bruno_v)]

Hannes J. schrieb:
> copy_from_eeprom_to_ram(&ram_destination, &(eeprom_source->common),
> sizeof(common_data));

und mit offsetof hätte die Zeile als zweiten Parameter offsetof (statt 
&), dass den meist notwendigen Cast nach size_t schon enthält.