MAL Wieder "C" Frust

[Ceos]

RS232 mit Windows API .... Strg + A, Strg + D, Strg + S .... wegrenn

ich pack mir immer eine POSIX UART Lib dazwischen ... sonst wird man beim setzen der serial struct irre

[Siro]

@Ceos:
Du meinst bestimmt die Struktur DCB, muss man mögen

Viel interesanter fand ich, um zu ermitteln wieviele Bytes sich im Empfangspuffer befinden,
muss man die Funktion "ClearCommError" aufrufen. Da muss man erstmal drauf kommen....
und da es keine UART Interrupts mehr gibt, habe ich diese Funktion nun in einen Timer packen müssen,
weil ich Zeitnah (sofern man das bei Windows überhaupt erwähnen darf) meine Daten haben wollte.

[HaWe]

gegen C ist eigentlich nichts zu sagen: es ist klar definiert, schreibt extrem wenig vor, kann so gut wie jede Hardware adressieren und händeln, hat nur knapp 20 fest definierte Bezeichner, eine extrem einfache Syntax, und die Executables sind rasend schnell.
Nicht umsonst werden ganze Betriebssysteme damit geschrieben (wozu es ja gerade entwickelt wurde).
Alles was du bemängelst, betrifft die libs, die andere Leute geschrieben und zu vertreten haben, und da gebe ich dir völlig Recht: da ist irrsinng viel Schrott unterwegs.

[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"