MAL Wieder "C" Frust

[Siro]

Hast Du nicht unrecht HaWe, jede Sprache hat Vor und Nachteile.
Ich hab aber doch immer wieder mal Probleme mit C die ich in Pascal nicht habe.
Mal abgesehen davon, dass es bei C99 wohl 190 Fälle gibt, wo nicht vorgeschrieben ist was der Compiler daraus machen soll...
Muste ich natürlich mit in meine Risikoanalyse aufnehmen....
https://www.elektronikpraxis.vogel.d...che-c-a-426198

Mich würde ja mal interessiren um welche Fälle es sich da handelt, falls da jemand Informationen oder Links zu hat, wäre ich sehr dankbar.

Zum Problem mit den Redistributablen von Microsoft:
Ich war mal, wie immer, experimentierfreudig ich habe die gesamten Microsoft Redistributables deinstalliert.....
Ältestes zuerst bis zum Aktuellsten.
Das Letzte liess sich nicht entfernen, vielleicht braucht das Windows selbst, keine Ahnung.
Aber nun konnte ich problemlos meine RIGOL Software installieren, was voher nicht ging.
Ich hatte übrignes nach der Deinstallation diverse Programme ausprobiert, ob sie davon betroffen sind.
OpenOffice
FireFox
Eagle
MCUXPresso
MPLAB
LAZARUS
keiner hatte Probleme, aber es war, wie gesagt, noch eine letzte Version vorhanden von 2017
viel mehr an Software läuft auch nicht auf meinem Rechner.

wenn ich jetzt sagen sollte, die Rigol Software läuft gut, müste ich lügen.
Das Bild auf dem Rechner entspricht nicht dem auf dem Oszilloskop Bildschirm.....Ohje.....
Wenn man das Programm verlässt und neu startet stimmt es wieder. Man darf nix am Ossi ändern, das bekommt die Software am PC anscheinend nicht mit.
Ist nicht perfekt, aber brauchbar...



Siro

[Ceos]

Mal abgesehen davon, dass es bei C99 wohl 190 Fälle gibt, wo nicht vorgeschrieben ist was der Compiler daraus machen soll...
Muste ich natürlich mit in meine Risikoanalyse aufnehmen....

Und das ist der Grund warum wir hier auf Arbeit keine schönen Dinge haben können (TM)

Wir haben Guidelines die uns gewisse Dinge verbieten ... So viele schöne Kontrukte die man bauen kann aber dann kommt der "nein das darfst du nicht"-Hammer weil "offsetof" nicht sauber spezifiziert ist

... und solch ähnliche Späße

Habe mir eine Standpauke über X-Makros anhören müssen .... mimimi statische Codeanalyse kann keine Functionpointer in Arrays verfolgen mimimi .... gut, jetzt ists halt ein ebenfalls per X-Makro generierter riesen-switch-case statt einer Spungtabelle ... der Compiler baut eh wieder ne Sprungtabelle draus aber wenigstens kann die statise Code analyse das jetzt verarbeiten

[Siro]

Moin Ceos
Ist doch mal schön zu hören, dass ich nicht der Einzige bin, der nach diversen Regeln arbeiten soll...
Wobei ich glücklicherweise NOCH keine wirklichen Vorgaben habe wie ich was implementiere.
Der Compiler macht eh was er will, das kann man kaum steuern.
Die wirklichen Probleme einer nicht funktionierenden Software liegen oftmals völlig woanders.
Das ist auch der Grund warum ich stets mit verschiedenen Optionen compiliere und teste.
Es finden sich immer wieder neue Merkwürdigkeiten, die oft sogar mit der Prozessorarchitektur zusammen hängen.
Das kann eh keine automatische Codeanlayse feststellen.

Ich habe auch Funktionstabellen, weil es wesentlich Übersichtlicher ist als ein switch-case.

"offsetof" kannte ich noch garnicht, witzigerwiese scheint das genau das zu sein, was ich für meine
EEPROM struktur verwende....
Was soll daran nicht "sauber" bzw. nicht nachvollziehbar sein ?

Im eeprom bei mir liegt ein struct, wo welcher Wert liegt ist nicht direkt bekannt, aber man kann es berechnen:

t_ee_struct *p;

  /* we dont know where the userdata is stored in the EEPROM */
  /* but we can calulate the address: */
  p = 0;  /* think the struct starts at address 0 */
  /* convert the pointer to a 32 Bit value (EE-ADDRESS) with the offset of setup_data */
  ee_address = (U32)(&p->setup_data);


// Deine genannte Variante mit offsetof  sieht doch VIEL besser aus, muss ich direkt mal ausprobieren .....
  ee_address = offsetof(ee_data,setup_data);

das macro hab ich grad gesichtet:

#define offsetof(struct_type, member) \
          (size_t) &(((struct_type *)0)->member)

Siro

[Ceos]

weil es nicht prozessorspezifische alignment regeln beachtet (zumindest laut spezifikation) ... also bei nicht "packed" structs oder wenn du bit access machst könnte es gut passieren dass du irgendwo in eine lücke geschickt wirst oder hinter das struct guckst oder auf der stelle trittst
es ist eben nicht "eindeutig"

[Siro]

Achso, ja, das packed hab ich drin:

/* the User preset range in the EEPROM was fixed to 16 Bytes */
/* these paramters can changed by the user in normal operation mode */
#pragma pack(1)  /* align the structure to bytes to minimize size */
typedef struct 
{
  U16  last_P10_pre;   /* last user Pressure for PRE-Insufflation */
  U16  last_Q10_pre;   /* last user Flow     for PRE-Insufflation */
  U16  last_P10_main;  /* last user Pressure for MAIN-Insufflation */
  U16  last_Q10_main;  /* last user Flow     for MAIN-Insufflation */
  BOOL last_Video;     /* last user Video on/Off state */
  U8   reserved1;
  U16  reserved2;
  U16  reserved3;
  U16  checksum;       /* CRC16 */    
} t_user_data;
#pragma pack()   /* end of packed structure */

hier "dürfte" es also keine Lücken geben, der Compiler "sollte" es Byteweise ablegen.
ohne das packed, wäre es gut möglich, dass er es auf die Standardbreite eines int aligned.

Probier ich gleich mal....

- - - Aktualisiert - - -

ich hab das grad mal probiert:

//#pragma pack(1)  /* align the structure to bytes */
typedef struct
{
  short a;
  char  b;
  short c;
} t_my_data;
//#pragma pack()   /* end of packed structure */


o = offsetof(t_my_data,c);

jo, hier verschiebt sich der Offset um 1 Byte

der Offset zu "c" ist unpacked = 4 bei packed = 3

der GNU-ARM Compiler macht das als richtig.

[Ceos]

fast alle machen das richtig, aber es ist halt nciht "spezifiziert" ... es KÖNNTE ja sei dass man IRGENDWANN mal einen exotischen compiler verwenden KÖNNTE der EVENTUELL ..... mehr sarkasmus und das forum erleidet einen schlaganfall, drum brech ich das mal ab XD

[Siro]

das steht ja in meiner Softwaredokumentation welcher Compiler verwendet wird...

Juti, sind wa durch, ich wünsche alleseits ein schönes Wochenende.

Habe wieder etwas dazu gelernt, mit dem MACRO: mir gefällt es

Siro