Ist es möglich mit einem GCC eine Software Zertifizierung durchzuführen oder werden an den Compiler gewisse Anforderungen gestellt? Wenn ja, welche sind diese?
:
Verschoben durch User
Wir mußten in der Firma meine Software zertifizieren lassen. Der "Prüfer" hat nicht nach einem Compiler gefragt. Es geht da eher um ein recht üppiges Honorar ...
Naja. Es gibt verschiedene Arten von Software Fehlern. Vorausgesetzt ist natuerlich dass der Compiler genau das macht, wie angewiesen. Was nicht dasselbe ist, was man denkt programmiert zu haben. - Ohne, resp zuwenig Typenpruefung. zB Pointer = int Das kann ein Compiler moeglicherweise, wenn er es denn soll. Allenfalls eine andere Sprache waehlen. - Falsche Abfragen : man laesst einen Index/Pointer zu wenig weit laufen. Das kann ein compiler natuerlich nicht herausfinden, es gibt auch keinen Runtime Fehler - Datenblatt falsch gelesen. Eine Funktionalitaet geht nicht zuverlaessig. Das kann ein compiler natuerlich nicht herausfinden, es gibt auch keinen Runtime Fehler - Konzept falsch. .. Bevor die Idde aufkommt, ein Compiler koenne "etwas"
Was für ein Zertifikat ist das denn? Schlimmstenfalls verlangt das Zertifikat, dass der Compiler sich an eine bestimme Version der ANSI-C-Spezifikation hält; damit hätte gcc kein Problem.
Armin schrieb: > Ist es möglich mit einem GCC eine Software Zertifizierung > durchzuführen > oder werden an den Compiler gewisse Anforderungen gestellt? Kommt auf die zertifizierung. Gehts um erhöhter Sicherheit wie bei der Fliegerei muss der Compiler darauf zertifiziert werden das er keine Scheisse baut. Das kann man per Analyse des Compilers selbst oder durch Blick auf die einsatz-hisory machen, meint wenn der Compiler in der Vergangenheit brauchbare Ergebnisse geliefert hat dann wird er das auch weiter tun. Natürlich bezieht sich diese aussage auf eine eingefrorene version des Compilers. Und oft wird verlangt Compiler-Optimierungen auszuschalten. Also prinzipiell kann man den Gcc zertifizieren, da seine Sourcen Offen liegen sollte das sogar einfach möglich sein. Aber Vorsicht, es gibt gcc-Varianten die verhalten lt. Linus sich wie auf ein Kopf gefallenes Faultier: http://www.heise.de/developer/meldung/Linus-Torvalds-wettert-gegen-Compiler-Collection-GCC-4-9-2268920.html Wer dir diese Version zertifiziert ist ein Scharlatan.
Clemens L. schrieb: > eine bestimme Version der ANSI-C-Spezifikation hält; damit hätte gcc > kein Problem. Klar. Gibt ja nur eine davon. :-) (Danach wurde die Standardisierung durch die ISO weitergeführt.)
Stichwoerter kann ich dich geben, weiter weisz ich nicht viel davon : Misra-C Splint
Armin schrieb: > Ist es möglich mit einem GCC eine Software Zertifizierung > durchzuführen > oder werden an den Compiler gewisse Anforderungen gestellt? Wenn ja, > welche sind diese? Hallo, da ich früher beim TÜV Rheinland sowas gemacht habe: Jein! Der GCC als Open Source ändert sich ständig, was heute zertifiziert wird ist morgen schon nicht mehr aktuell. Es gibt kein richtiges QM System, keine Ansprechpartner. Kundenfeedback meist auch nicht, wer meldet sich schon in den Bug Foren an?. In der FS gehört das aber nach 61508 alles dazu. GCC ist ein Tool von Hobbyisten. In der Funktionalen Sicherheit wirst Du auf zertifizierte Tools zurückgreifen müssen, Werkzeuge wie Lint verwenden, MISRA anwenden usw. Grosse Firmen verwenden daher immer Keil, IAR, Greenhills usw. Gruss, Christian
Christian J. schrieb: > da ich früher beim TÜV Rheinland sowas gemacht habe: Jein! Der GCC als > Open Source ändert sich ständig, was heute zertifiziert wird ist morgen > schon nicht mehr aktuell. Ach, und das ist bei anderen Compilern anders? Eine Zertifizierung wirst du wohl immer nur mit einer ganz konkreten Version eines Werkzeugs vornehmen können – und diese ändert sich hernach nicht mehr. > Es gibt kein richtiges QM System Was ist denn Bugzilla dann? Der GCC hatte sowas schon, als es sonst so gut wie noch keine Software gab, die mit solchen Mitteln gearbeitet hat. Ich kann mich noch gut dran erinnern, wie erstaunt ich war, als ich Anfang der 1990er Jahre ca. 1 Jahr nach dem Berichten eines Bugs (dürfte um Motorola m88k gegangen sein, mit denen wir damals gearbeitet haben) eine Mail bekam, dass der Bug repariert worden war. War meiner Erinnerung nach ein internal compiler error, der ja ausdrücklich dazu aufforderte, berichtet zu werden. Ich verstehe deine Einwände, aber diese beiden da oben sind hanebüchen.
Christian J. schrieb: > da ich früher beim TÜV Rheinland sowas gemacht habe: Jein! Der GCC als > Open Source ändert sich ständig, was heute zertifiziert wird ist morgen > schon nicht mehr aktuell. Wo ist das Problem? Übliches Vorgehen: VM/Rechner einrichten, Tools, IDEs, Editoren, Compiler, Frameworks etc. pp installieren, Projekt bearbeiten, VM/Rechner archivieren. Ansonsten kann es immer zu Problemen kommen. > Es gibt kein richtiges QM System, keine > Ansprechpartner. Kundenfeedback meist auch nicht, wer meldet sich schon > in den Bug Foren an?. In der FS gehört das aber nach 61508 alles dazu. > GCC ist ein Tool von Hobbyisten. http://www.adacore.com/gnatpro-safety-critical/avionics/ GNAT sprich gcc > Grosse Firmen verwenden daher immer Keil, IAR, Greenhills usw. Wie wärs denn mal mit Statistik? Menge des Quelltextes, der durch diese Compiler gegangen ist, Anzahl der Plattformen und getesteten Betriebsbedingungen/Installationen vs. das, was demgegenüber durch den gcc gegangen und getestet wurde...
:
Bearbeitet durch User
> Ach, und das ist bei anderen Compilern anders?
Ja, ist es. Du bezahlst naemlich IAR extra dafuer das sie sich um den
zertifizierten Compiler kuemmern. Das kostet $$$$$$.
Olaf
Olaf schrieb: >> Ach, und das ist bei anderen Compilern anders? > > Ja, ist es. Du bezahlst naemlich IAR extra dafuer das sie sich um den > zertifizierten Compiler kuemmern. Du hast das Zitat aus dem Kontext gerissen. Es ging darum, dass der GCC sich ständig weiterentwickelt und angeblich nur deshalb gar nicht zertifizierbar wäre. Im Umkehrschluss würde das ja unterstellen, dass IAR seinen Code nicht mehr weiterentwickelt. Tun sie es doch (ganz gewiss tun sie's), dann ist das aber kein Unterschied mehr zum GCC. (Dass eine zertifizierte Version eines Compilers gewiss eine gute Sache ist, stelle ich keineswegs in Frage.)
Jörg W. schrieb: > (Dass eine zertifizierte Version eines Compilers gewiss eine gute Sache > ist, stelle ich keineswegs in Frage.) Diese Firmen informieren ihre Kunden ständig über Neuerungen, du hast eine Hotline wo Du sofort einen dran hast, Du hast geprüfte neue Libs und wirst nicht zum Beta Tester missbraucht. Und das kostet nur mal Asche. Peanuts gegenüber einem fehlerhaften Produkt. Ich verweigerte jedenfalls den GCC immer für SIL Produkte und tue das auch heute noch.
Christian J. schrieb: > Diese Firmen informieren ihre Kunden ständig über Neuerungen Man könnte auch sagen: sie gehen einem damit auf den Keks. Ist ja nicht so, dass ich nicht auch schon einen IAR in der Hand gehabt hätte. > Und das kostet nur mal Asche. Wieviel kostet denn die zertifizierte Version so? Selbst die kleinste Normalversion eines IAR kostet ja schon ein halbes Vermögen.
Sonst gaebe es noch Ada. Da kommt nur Zertifiziertes auf den Markt. Alle paar Jahrzehnte kommt eine ueberarbeitete Sprachversion, mit neuen Features. Abgeshen davon braucht ein Compiler eigentlich nur eine Ueberarbeitung wenn man einen neuen Controller unterstuetzen will, dann wird der Codegenerator ausgewechselt, der Parser, der die Sprache ausmacht bleibt derselbe. Ein Ada Compiler ist sehr teuer, dafuer weiss man was man hat.
Armin schrieb: > Ist es möglich mit einem GCC eine Software Zertifizierung > durchzuführen > oder werden an den Compiler gewisse Anforderungen gestellt? Wenn ja, > welche sind diese? Die Frage ist: Welche Art von Zertifizierung ? Luftfahrt ? Nein, GCC reicht nicht.
Jörg W. schrieb: > Wieviel kostet denn die zertifizierte Version so? Selbst die kleinste > Normalversion eines IAR kostet ja schon ein halbes Vermögen Häh? Der normale IAR für C für Arm mit Misra und einigem Schnickschnack mehr kostet immer noch ca 5000 Euro als Einzelplatzzversion.
> Grosse Firmen verwenden daher immer Keil, IAR, Greenhills usw. Keil in dem Zusammenhang zu erwähnen finde ich schon mutig. Der 8051-Compiler von denen um 2012 rum (Version 9irgendwas) hatte Bugs, die eher nach sdcc 0.001 klangen. Hab mich mit dem Dreck tagelang abgemüht, um dann (natürlich in einer kaum debugbaren Interrupt-Routine) ein Problem beim langweiligen Schieben eines 32Bit-Werts zu finden. Die anderen erschreckend trivialen Errata bzw. Fixed-Listen in den Release-Note deuten auch darauf hin, dass Keil eher eine Frickelbude ist. Solange mir kein Kunde Keil vorschreibt, werde ich auch für ARM den Mist nicht mehr anfasse, egal wieviele bunte Zertifizierunglogos es hat.
Christian J. schrieb: > Der normale IAR für C für Arm mit Misra und einigem Schnickschnack mehr > kostet immer noch ca 5000 Euro als Einzelplatzzversion. Ja, für eine node-locked-Variante als Einzelplatz finde ich das schon heftig teuer(*). Selbst Altium zockt ja da noch weniger ab. Deshalb frage ich mich dann, wieviel die zertifizierte Variante wohl kostet. (*) Nicht nur ich. Ich habe mal eine Bitte eines Atmel-FAE um Unterstützung erhalten, weil er einem größeren Kunden dabei helfen musste, von IAR auf GCC umzusteigen. Für einen Pool von nightly builds war denen dann der IAR wohl doch zu teuer geworden. Ist jetzt schon einige Jahre her, aber an der Preispolitik von IAR hat sich ja nichts grundlegend geändert seitdem.
Totaler Blödsinn! Ich kenne mehrere Beispile wo der gcc für SIL2 und 3 Projekte erfolgreich akzeptiert wurde. Ich behaupte jetzt mal, da war auch der TÜV Rheinland unter den abnickern. Die Frage ist doch eher wie groß der Aufwand zum Nachweiß der Korrektheit des Compilers ist für den jeweils generierten Code. Das ist keine einfache Sache und auch nicht in 1-2 Wochen getan. Hier lohnt es sich schnell auf ein zertifiziertes Produkt zu setzen. Bin selbst unter anderem für Compiler Validierung zuständig!
squierrel schrieb: > Die Frage ist doch eher wie groß der Aufwand zum Nachweiß der > Korrektheit des Compilers ist für den jeweils generierten Code. Das ist > keine einfache Sache und auch nicht in 1-2 Wochen getan. Hier lohnt es > sich schnell auf ein zertifiziertes Produkt zu setzen. > > Bin selbst unter anderem für Compiler Validierung zuständig! Das ist der eigentlich ausschlaggebende Punkt. Ein Compiler mit den notwendigen Zertifikaten vermindert den Papierkrieg, sagt aber nix über die Qualität des Compilers im jeweiligen Anwendungsfall selbst aus.
GCC wird auch im Bereich Automotive eingesetzt (z.B. TriCore, PowerPC VLE), und zwar an zentraler Stelle wie z.B Steuergeräten. Die Hersteller, die entsprechende Steuergeräte in ihren Karren verbauen, setzen dementsprechend auch GCC sein. Und nein, der Grund ist nicht, weil GCC "nix kostet". Entsprechend gepflegte Versionen mit Longtime-Support und den gewünschten — ich nenn es jetzt mal Features — sind nämlich alles andere als billig.
:
Bearbeitet durch User
Christian J. schrieb: > GCC ist ein Tool von Hobbyisten. In der Funktionalen Sicherheit wirst Du > auf zertifizierte Tools zurückgreifen müssen, Werkzeuge wie Lint > verwenden, MISRA anwenden usw. Da muss ich nun aber arg schmunzeln. Ada/GNAT wurde ja schon erwähnt, spätestens seit egcs dürfte die Zeit der "Hobbyisten" vorbei sein. Für so einige Architekturen, dazu gehören v.a. ARM, Intel und MIPS, dürften die gcc tools (dazu zähle ich auch div. Anverwandte OS-Tools wie gcov, valgrind, usw) nicht mehr in der Robustheit zu schlagen sein - man muss sich nur die richtigen Versionen besorgen. Die Frage ist, ob man einer Bude Vertrauen schenkt, die eine Menge heisse Luft für ein Zertifikat fabriziert, oder einem Tool, das man selbst mit dem OS zusammen Regress-testen kann (und das kann man bei GCC). Bei Keil habe ich da so meine Zweifel, deren 8051-Compiler flog auch bei mir in die Ecke und die Cortex-M0-Sachen liefen eher so naja. Und die IAR-Tools (ok, 10 Jahre her) waren im Vergleich mit dem msp430-gcc eine Zumutung. Da ist das Vertrauen auch erst mal weg. Eine Zertifizierung macht auch nur für die entsprechend verifizierte und Regress-getestete Architektur Sinn. Da nützt die beste Compiler-Norm nix, wenn unter gewissen Bedingungen bei Interrupt soundso und Befehl X der Cache nen Schluckauf bekommt. Mir ist ehrlich gesagt ein Werkzeug lieber, über das 1000 Augenpaare als nur die von einer Handvoll gelangeweilter Prüfer drübergehen. Frei nach dem Motto: Trau, schau wem. Schlussendlich muss sich eine Firma überlegen, was billiger kommt: das Risiko, einer third party zu vertrauen, oder selber den Aufwand zu treiben um beweisen zu können, dass das System allen möglichen Fehlerszenarien standhält. Schlussendlich ist man da schnell mal hinter dem Compiler und zertifiziert nur noch die korrekte Funktion des generierten Assemblercode für genau ein spezielles Programm - oder man spart sich Zertifizierungsstress, indem man es in Hardware (HDL) umsetzt, da wird die Model in the Loop-Verifizierung schon simpler.
Fitzebutze schrieb: > Und die IAR-Tools (ok, 10 Jahre her) waren im Vergleich mit dem > msp430-gcc eine Zumutung. Die Erfahrung habe ich allerdings nicht gemacht. Als ich den GCC für den MSP430 das letzte Mal in den Fingern hatte, war er vor allem mit Devices mit mehr als 56 KiB Flash (wie sie unser Kunde natürlich benutzt hat …) ein ziemlicher Bastelsatz. Das lag aber wohl vor allem daran, dass die Version von TI damals noch offline gepflegt worden ist, weil sie dem Hörensagen nach ihre Copyright-Abtretung an die FSF noch nicht machen wollten oder konnten. Auf diese Weise ständig den GCC-Entwicklungen hinterherrzulaufen ist ein ziemliches Schießen auf ein bewegliches Ziel … Mittlerweile sollte er wohl im offiziellen GCC integriert sein, aber mittlerweile habe ich nichts mehr mit MSP430 zu tun. Dafür lief dann das tolle TI-FET nicht in der VMware. IAR gab TI die Schuld, TI hat sich nie wieder gemeldet (trotz eines ausgiebigen USB-Traces). Ist das einzige USB-Gerät, was ich bislang in VMware nicht zum Laufen bekommen hatte. Zum Glück ging dann ein billiges Launchpad als Debugger (das wiederum ging aber auch problemlos auf dem Linux-Host).
Stand 2003: Da war es in der Medizintechnik (Infusionstechnik) noch so das der Compiler eher unwichtig war. Für den Prozessor gab es damals aber auch nur Keil und IAR, der wurde bei start der Entwicklung eingefroren und noch für weitere Produktversionen beibehalten. Klar wurde der irgendwann auch mal aktualisiert, meistens wenn es grössere Produktänderungen gab. Der Code musste durch die gängigen Tools laufen wie LINT. MISRA war da noch nicht so verbreitet, auch wenn ich privat das schon kannte. Zum Abschluss gab es hunderte Seiten Testpunkte abzuarbeiten um mögliche Fehler zu finden. Klar was das nicht ein 100% Test aber den Tests würde ich noch heute mehr vertrauen wie jedem Zertifikat.
Jörg W. schrieb: > Clemens L. schrieb: >> eine bestimme Version der ANSI-C-Spezifikation hält; damit hätte gcc >> kein Problem. > > Klar. Gibt ja nur eine davon. :-) > > (Danach wurde die Standardisierung durch die ISO weitergeführt.) Und die alten Versionen gibt es eigentlich offiziell nicht mehr. Wenn eine neue Version der ISO-Norm rauskommt, werden dabei alle vorhergehenden Versionen (auch die ANSI) für ungültig erklärt. Somit gibt es (im Sinne einer gültigen Norm) sowieso immer nur eine.
Zertifizierung ist Schlangenöl. Der Compiler war meistens noch das sicherste und am besten getestete ?
Georg A. schrieb: > Keil in dem Zusammenhang zu erwähnen finde ich schon mutig. Der > 8051-Compiler von denen um 2012 rum (Version 9irgendwas) hatte Bugs, die > eher nach sdcc 0.001 klangen. Hab mich mit dem Dreck tagelang abgemüht, > um dann (natürlich in einer kaum debugbaren Interrupt-Routine) ein > Problem beim langweiligen Schieben eines 32Bit-Werts zu finden. Die > anderen erschreckend trivialen Errata bzw. Fixed-Listen in den > Release-Note deuten auch darauf hin, dass Keil eher eine Frickelbude > ist. Solange mir kein Kunde Keil vorschreibt, werde ich auch für ARM den > Mist nicht mehr anfasse, egal wieviele bunte Zertifizierunglogos es hat. Zertifizierte Bugs sind gut, kostenlose sind schlecht. Deshalb lieber viele zertifizierte!
Wie läuft denn die Zertifizierung eines Compilers ab? Da wird ja wohl kaum einer "mal kurz" den gesamten Code anschauen und dann bescheinigen, dass kein Bug drin ist. Geht es bei einer Zertifizierung überhaupt in irgendeiner Weise um die Häufigkeit von Bugs oder eher um die Prozesse außenrum. Also dass auch die Einrückung überall im Code gleich ist und das man schön nach MISRA programmiert, und dass Bugreports irgendwo abgelegt werden?
Rolf M. schrieb: > Wie läuft denn die Zertifizierung eines Compilers ab? Da wird ja wohl > kaum einer "mal kurz" den gesamten Code anschauen und dann bescheinigen, > dass kein Bug drin ist. Du suchst dir eine Zertifizierungsstelle und erhöhst das Honorar solange, bis du einen Stempel bekommst. Glaubst du ernsthaft, mann kann an einem Compiler irgendwas zertifizieren? Natürlich, den Prozess drumherum kann man zertifizieren. Ein halber Regalmeter DIN/ISO/EN im Dunstkreis der 61508 dreht sich nur darum, und zwar meilenweit abstrakt und anhand von Beispielen und Empfehlungen von vor 40 Jahren. Guck doch mal, wie lange das Audit von TrueCrypt gedauert hat und was dabei herauskam. Und vergleiche dann mal, wie viel umfangreicher ein durchschnittlicher Compiler ist. Wenn man bedenkt, dass manche Zertifizierungsstellen mit Umlaut im Namen sogar Software zertifizieren, ohne Quelltext zu sehen, naja. Software-Zertifizierung ist Handel mit Schlangenöl.
Hat zwar nur was bedingt mit Zertifizierung zu tun: Gibt es denn vielleicht irgendeinen Satz Dateien, welcher verschiedenste Berechnungen und Konstrukte ausführt und das Ergebnis auf Gültigkeit prüft? Ich stell mir gerade z.B. ein paar mathematische Berechnungen vor mit allen möglichen Datentypen. Oder z.B. sin/cos/tan mit ein paar Beispielwerten. So dass man diese dann durch den Compiler (mit aktuellen Einstellungen an Options) werfen kann und sieht, ob grob was falsch ist. Ok, der Teufel steckt im Detail, alles wird er dadurch auf jeden Fall nicht finden. Vielleicht muss der Test auch immer wieder aktualisiert werden, wenn neue Compiler-Fehler (verschiedenster Compiler) gefunden werden. Und es muss die "Test-Suite" natürlich auch immer wieder neu ausgeführt werden, wenn man eine neue Compiler-Version oder gar einen anderen Compiler einsetzt.
A. Horn schrieb: > Gibt es denn vielleicht irgendeinen Satz Dateien, > welcher verschiedenste Berechnungen und Konstrukte ausführt > und das Ergebnis auf Gültigkeit prüft? https://gcc.gnu.org/testing/ http://llvm.org/docs/TestingGuide.html
A. Horn schrieb: > Oder z.B. sin/cos/tan mit > ein paar Beispielwerten. Ein klassischer Test für Gleitkomma ist
Da sollte ohne Rundungsfehler 20 rauskommen.
Vielen Dank euch beiden! @Clement Zweiter Link geht bei mir gerade nicht (Firefox timed aus), probiere ich später nochmal. Gibt es so etwas auch nur für C (statt C++) bzw. weißt du, ob in den C++ Tests auch welche enthalten sind (vielleicht ein Subset), welche für C geeignet sind. Bei Boost denke ich, wird auf jeden Fall C++ benötigt?
A. Horn schrieb: > Hat zwar nur was bedingt mit Zertifizierung zu tun: > Gibt es denn vielleicht irgendeinen Satz Dateien, > welcher verschiedenste Berechnungen und Konstrukte ausführt > und das Ergebnis auf Gültigkeit prüft? > Ich stell mir gerade z.B. ein paar mathematische Berechnungen vor > mit allen möglichen Datentypen. Oder z.B. sin/cos/tan mit > ein paar Beispielwerten. Da muss man dann aber auch schon sehr aufpassen. Wenn man die Werte als Konstanten übergibt, wird ein halbwegs optimierender Compiler die Berechnung selber durchführen. Wenn das nicht geht, werden sie zur Laufzeit auf dem Zielrechner ausgeführt. Schon hier kann es gerade bei Cross-Compilern unerwartete Unterschiede geben. Bessere Compiler versuchen dabei soweit ich weiß, das Verhalten des Zielsystems zu emulieren, um sicherzustellen, dass das Ergebnis gleich ist. Aber auch da können Fehler drin sein. Die nächste Frage ist, ob es überhaupt ausreicht, die Software ohne die Berücksichtigung der Hardware zu testen. Auf dem Pentium I mit seinem berühmten FDIV-Bug kann ja z.B. auch wieder was anderes rauskommen, wenn das nicht im Compiler berücksichtigt wird. > So dass man diese dann durch den Compiler (mit aktuellen Einstellungen > an Options) werfen kann und sieht, ob grob was falsch ist. Ich schätze mal, dass die Fehler tendenziell eher weniger in so Funktionen wie sin() stecken, sondern eher darin, dass in ganz bestimmten Situationen z.B. eine if-Abfrage nicht korrekt funktioniert, weil irgendwelche Vergleiche falsch umgesetzt werden. > Und es muss die "Test-Suite" natürlich auch immer wieder neu ausgeführt > werden, wenn man eine neue Compiler-Version oder gar einen anderen > Compiler einsetzt. Oder wenn man irgendwelche Compiler-Optionen ändert.
Ok, LLVM-Link ging mittlerweile. Darin gibt es eine test suite (in meinem Fall Version 3.7.1). Wieder darin SingleSource\Regression\C. Dies geht schon in die Richtung, was man für einen groben Test eines (Embedded-/Cross-) Compilers benutzen könnte. Aber darin gibt es malloc, stdargs, printf, ... Alles, was man meist nur Bare-Metal Embedded System nicht hat. Und gar viele Testcases sind es auch nicht.
A. Horn schrieb: > Aber darin gibt es malloc, stdargs, printf, ... > Alles, was man meist nur Bare-Metal Embedded System nicht hat. Mit Bare-Metal (kein OS) hat das nix zu tun. malloc, stdargs, printf, ... sind Teil des Standards. Auch wenn solche Features in Anwendungen eher unüblich sind, tut ein Toolhersteller gut daran, diese zu unterstützten. avr-gcc zum Beispiel unterstützt all diese Features und durchläuft die "normalen" GCC-Testsuites. > Und gar viele Testcases sind es auch nicht.
Nun, tests gehören eigentlich zu jedem guten Compiler (Beispiel aus
SDCC, sdcc/support/regression):
> make test-stm8
[…]
Summary for 'stm8': 0 failures, 9433 tests, 1765 test cases, 2050582
bytes, 7775005 ticks
Bei SDCC entstehen die Tests haupstächlich auf folgendem Weg: 1) Bei
Implementierung neuer Features 2) Beim Beheben von Bugs 3) Von GCC
übernommen.
Solche Tests sind meiner Meinung nach sehr wichtig, aber mit
Zertifizierung haben sie erstmal nichts zu tun.
Philipp
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.