Nachdem mir beim über 1000 EUR teuren Compiler von IAR aufgefallen ist,
dass der Bugs wie falsche Berechnung von Bitfeld-Größen, kein printf
mit %hu u. %u, kein sscanf von %3s, fehlerhaftes longjmp usw. hat
(wobei es nicht einmal warnings gibt) und nicht einmal kritisches wie
if(a=b) oder sinnloses/offensichtlich falsches wie {a == b} meldet,
interessiert mich ob das im embedded-Bereich normal ist.
Compiler wie gcc / MSPGCC haben solche Bugs und Semantik-Blindheit ja
nicht.
Dann versuch doch mal den AVRGCC. Soll aber keine Bewertung sein, bin kein C-Freak. Gruß, Frank
Für die printf-Formatierung gibt es u.a. folgende Optionen: Conversion Argument Converted Default Pre- Specifier Type Value Base cision %u int x (unsigned int)x 10 1 %hu int x (unsigned short)x 10 1 %lu long x (unsigned long)x 10 1 Dem Linker muß man aber mitteilen, welchen Umfang/Parameter formatted_write zulassen soll (Codegröße). >> kritisches wie if(a=b) oder sinnloses/offensichtlich falsches wie >> {a == b} meldet, Die 1. Form benutze ich in z.B.: while(c = lese_taste()); Ein Meckern des Compilers würde mich nerven. GCC für den H8S meckert glücklicherweise auch nicht ! Die 2. Form erzeugt bei mir eine Warnung: expression has no effect Der Compiler hat auch Macken und Tücken; aber ob alle Deine obigen Feststellungen zustreffen, weiß ich nicht. Vielleicht sind einige 'Schalter' nicht richtig verwendet. Wenn Du soviel Geld ausgegeben hast, solltest Du Dich intensiver mit Deiner Investition befassen.
> Für die printf-Formatierung gibt es u.a. folgende Optionen: > ... Ja, im Prinzip schon, aber wenn ich %hu oder %u angebe, bekomme ich nur u ausgegeben; das sprintf vom IAR-Compiler kennt %hu u. %u nicht und meldet das nicht einmal! Für mich ist sowas Sabotage, denn der Sourcecode ist korrekt, aber das Ergebnis nicht. Mit sscanf Datum und Zeit aus _DATE__ und __TIME_ auszulesen ist auch nicht möglich, obwohl es nicht einmal eine Fehlermeldung gibt! Da musste ich extra in ein array kopiern, 0x00 einfügen und jede Variable mit atoi bzw. strcmp einlesen/vergleichen! > Die 1. Form benutze ich in z.B.: while(c = lese_taste()); Naja, im Prinzip richtig, aber das ist zumindest bei der Zuweisung einer Variablen fehlerträchtig und sollte eine Warnmeldung produzieren, denn in 99 % aller Fälle ist das erfahrungsgemäß wirklich ein Fehler, weil dort a == b gemeint war, aber tatsächlich a = b geschrieben wurd. > Die 2. Form erzeugt bei mir eine Warnung: expression has no effect Ja, das bin ich u. a. vom gcc so gewohnt und deshalb hat es mich erstaunt, dass es überhaupt noch so einen sch*** Compiler gibt, der zudem teuer ist und ein Dongel verlangt. Dazu kommt ja noch, dass die IDE von IAR nicht einemal einen Semantik-Checker enthält! Dass da das Revisionsverwalungssystem fehlt und Datenmüll im Projekt-File angesammelt werden sind da noch die geringsten Probleme.
Vorab: ich kenne den IAR-Compiler praktisch nicht. @Michael: > Die 1. Form benutze ich in z.B.: while(c = lese_taste()); Ein > Meckern des Compilers würde mich nerven. GCC für den H8S meckert > glücklicherweise auch nicht! Zumindest mit -Wall sollte er es warnen. Workaround: while ((c = lese_taste())) ; Das doppelte Klammerpaar nimmt er als Indikation, daß der Programmierer das wirklich so wollte. @Rolf: > ... das sprintf vom IAR-Compiler kennt %hu u. %u nicht und meldet > das nicht einmal! Wohin soll es das dann auch melden? printf/scanf Formatstrings werden doch zur Laufzeit geparst. (OK, dem IAR würde ich zutrauen, daß sie die Bibliothek mit dem Compiler so eng verflochten haben, daß der Compiler eigentlich wissen könnte, was in der Bibliothek tatsächlich implementiert ist. Bei der deutlich stärkeren Trennung von Bibliothek und Compiler im GCC aber wäre eine solche Meldung schon viel schwieriger.) > Mit sscanf Datum und Zeit aus _DATE__ und __TIME_ auszulesen ist > auch nicht möglich, obwohl es nicht einmal eine Fehlermeldung gibt! Für die Fehlermeldung gilt das gleiche wie oben. Ansonsten: Du mußt Dir halt bei einem Controller stets gründlich Gedanken darum machen, was der Compiler aus Deinem Geschriebsel denn überhaupt tun kann. Meines Wissens legt der IAR konstante Strings (und zu sowas evaluieren _DATE__ und __TIME_ letzlich) im ROM ab. Das mußt Du dann dem scanf() aber auch irgendwie sagen, da es mit an Sicherheit grenzender Wahrscheinlichkeit standardmäßig seine Strings aus dem RAM parsen will. Die Harvard-Architektur des AVR läßt grüßen, für Compilerhersteller ist das schon nicht so einfach. Beim AVR-GCC müßtest Du Dir um Strings im ROM dann stattdessen selbst Gedanken machen, da der GCC mit Harvard praktisch überhaupt nicht umgehen kann. Dafür würde Dein Beispiel zwar funktionieren (weil der AVR-GCC auch konstante Strings standardmäßig in den RAM legt), aber es würde zur Laufzeit permanent RAM gebunden für die Strings.
@Rolf: in frmwri.c werden verschiedene #define verarbeitet
-DFLOAT_SUPPORT Full ANSI formatter
-DNO_FLOATS Full ANSI except floats
-DREDUCED_SUPPORT Reduced 'int' type of converter
Beim Linken wird mit -e_small_write oder -e_medium_write festgelegt, ob
die schlankeren Versionen verwendet werden sollen.
Die IDE verwende ich garnicht: ich schreibe u.a. eine .mak und eine
.xcl (Linkerscript) Datei und starte alles in einem DOS-Fenster, wie
sich das gehört mit cc.bat :-)
Aber die IDE sollte doch selbsttätig eine .xcl erzeugen, die man sich
auch ansehen kann. Da ich auch schon andere Compiler von diesem
Hersteller seit Jahren verwende, habe ich das Glück, auch noch viele
Quellen der .lib zu haben. 'Früher' mußte/konnte man sich seine
bevorzugte .lib noch selber generieren; Dongle gab's auch nicht.
Früher war eben alles besser.
Mein letzter Fehler (den ich gemerkt habe) mit dem Compiler war das
vollständige Wegoptimieren einer Zuweisung 'flag = 1;' in einer
kleinen, überschaubaren Funktion. Funktion war getestet, alles lief,
bis eines Tages mit gewachsener Codegröße das globale 'flag' nicht
mehr gesetzt wurde. Der Fehler zeigte sich selbstverständlich an einer
ganz anderen Stelle. Erst ein 'volatile char flag;' ließ die
Zuweisung wieder auftauchen. Die Frage nach Compiler-Qualität könnte
man auch so formulieren: Wo sind die Schmerzen am geringsten?
Also brauche ich einen Compiler-Test, der longjmp, sscanf, fprintf usw.
testet u. die Bugs auflistet sowie anzeigt, welche Warnungen (z. B. für
{a==b;}ausgegeben werden sollten. Ein Compiler, der bei {a==b;} nicht
einmal eine Warnung ausgibt ist schließlich sinnlos (wenn man nicht
ständig einen Semantik-Checker benutzt); da kann ich ja gleich
Assembler nehmen.
Welche Compiler-Tests gibt es denn?
Also ich habe mal angefangen und folgenden Minimal-Test geschrieben:
// Minimal compiler test for C compiler.
//
// The compiler MUST produce the warnings like these in the comments
// below if he should be used for programming more than hello world
programs,
// because humans do produce often such semantik errors!
void
main (void)
{
int a, b, c, d, e, f, g, h;
if (a = b) // warning: suggest parentheses around assignment
used as truth value
c = d << e + f; // warning: suggest parentheses around + or -
inside shift
g == h; // warning: statement with no effect
}
Wie gesagt besteht der gcc diesen Test und der ICC430 vom IAR Embedded
Workbench 1.26A Vollversion (mit Dongle) versagt auch bei allen
aktivierten Warnungen/Fehlermeldungen völlig!
Sowas schrottiges wie ICC430 verkauft ja nicht einmal Microsoft!
Naja, die Berichte von Hardware-Herstellern (TI) sowie in ELV und
FUNKAMATEUR sollte man wohl nie ernst nehem.
Mal sehen was ich an Semantik-Checkern als Workaround für diesen sch***
Compiler nehemn kann.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.