Newsgroups: de.comp.lang.c
Von: Rainer Weikusat
Datum: Thu, 18 Mar 2004 10:27:00 +0100
Betreff: Re: MISRA-Standard Quellen?
Vinzent 'Gadget' Hoefler writes:
> Rainer Weikusat wrote:
>>"R.Freitag" writes:
>>> Der MISRA-Standard definiert bestimmte, der Robustheit und Wartbarkeit
>>> fördernde Richtlinien zur Programmierung in C.
>>Nein.
> Naja, einiges wuerde ich zumindest als brauchbar bezeichnen.
Das schließt sich nicht aus.
> |Only expressions concerned with loop control should appear within a
> |for statement.
> Komisch finde ich eher, dass man so was in speziellen Guidelines
> schreiben muss und das nicht generell zum common sense gehoert.
Deswegen halte ich das Verfahren auch für 'eher unsinnig': Gesetzt den
Fall, es gäbe tatsächlich jemand, dem man solche Anweisungen an die
Hand geben muß, um Unbill zu verhüten: Kann ich in endlicher Zeit eine
'wasserdichte' Richtlinie für sowas verfassen oder ließe sich
das vielleicht unaufwendiger lösen, in dem ich ihm/ihr einen Lolli oder
sonst etwas nettes, buntes und harmloses in die Hand drücke, und die
eigentliche Arbeit selber mache? Und wie schütze ich den Inhalt dieser
Richtlinie davor, zB als vollkommen gegenteilig zur ihrer Intention
'interpretiert' zu werden? Menschen sind ziemlich gut darin, plausibel
scheinende Gedankengebäude zu errichten, die einen a priori
feststehenden Standpunkt 'begründen'.
Hinzu kommt noch, daß Stilvorschriften auf statement-Ebene niemanden
daran hindern, Zehntausendzeilen-'Skripte' (was scheinbar viele Leute
unter 'Programmen' verstehen) mit der Binnenstruktur eines Knorpels zu
verfassen. Gröbere Anweisungen wie 'ein dokumentierter Entwurf wird
erstellt' halte ich da für sinnvoller (was natürlich 'in der Praxis'
mit 'Warum muß das dokumentiert werden, solange das GUI stabil läuft'
kolldiert :-( ).
Newsgroups: de.comp.lang.c
Von: Rainer Weikusat
Datum: Fri, 19 Mar 2004 23:12:50 +0100
Lokal: Fr. 19 Mrz. 2004 17:12
Betreff: Re: MISRA-Standard Quellen?
"Herbert Rosenau" writes:
> Wenn Menschenleben an einem winzigen Fehler hängen können, können
> Regeln nicht scharf genug sein.
Das ist vollkommener Bullshit. Produktqualitaet erreicht man nicht
durch drakonisches tyrannisieren der 'Produzierenden', sondern durch
eine Qualitaetskontrolle anhand objektiv ueberpruefbarer
Kriterien. Dazu zaehlt nicht subjektive Vorlieben irgendwelcher
Personen fuer ihre eigenen Geistesprodukte, wie zB projektierte
Programmierpsrachen, fuer die es noch nicht mal Compiler gibt.
[...]
> steigert die Sicherheit des Codes auch noch ein wenig.
Falls Du die 'Sicherheit' von Code steigern moechtest, solltest Du ihn
verschluesseln. Das was Du allerdings meinst, ist binaer:
Vorhandensein von Fehlern, die bestimmte Konsequenzen haben. Die sind
entweder vorhanden, oder sie sind das nicht. Die Frage laesst sich
beantworten und falls die Anwort 'ja' lautet, spielt die
Wahrscheinlichkeit, mit der nach Massgabe von
$unquantifizierbare_kriterium danach zu rechnen geswesen ware, das die
Antwort ja gelautet haette, falls jemand sich die Muehe gemacht
haette, das zu ueberpruefen, keine Rolle.
> Man wird gezwungen an den else Zweig zu denken und den auch
> auszuformulieren - und wenn mit einem leeren statement.
Wenn x dann tue blah, andnernfalls ... ups
... ismirnursorausgerutscht?
Newsgroups: de.comp.lang.c
Von: Rainer Weikusat
Datum: Sat, 20 Mar 2004 01:04:12 +0100
Lokal: Fr. 19 Mrz. 2004 19:04
Betreff: Re: MISRA-Standard Quellen?
"Ralf Neuber" writes:
> Wann immer eine Behörde wie TÜV, BiA eingeschaltet werden muss zur Abnahme
> der Software werden diese Regeln erwartet. HIS ist denke ich der selbe Weg.
> Schliesslich werden ja so viele Prozesse ausgelagert auf Zulieferer, dass
> man ganz einfach eine gewisse Form definieren muss.
Die 'gewisse Form' ist aber bereits definiert, naemlich in der
Sprachdefinition. Falls jemand eine 'gewisse andere Form' moechte,
sollte er das sinnvollerweise so machen, einen Compiler zu
implementieren, der die Einhaltung dieser Form gewaehrleistet,
*anstatt* einem Menschen, der ohnehin schon von alleine Fehler machen
wird, noch zusaetzlich mit dem Auswendiglernen und Beachten
sachfremder Vorschriftenkataloge zu belasten. Dadurch wird der
naemlich *mehr* Fehler machen, anstatt weniger, weil er mehr
Entscheidungen treffen muss.
> Selbst wenn manche Regeln von MISRA bei einem Release bewusst gebrochen
> werden -> wenn es begründet+logischerweise geschieht hat keiner was
> dagegen.
Eine 'Regel', die man 'logisch und begruendet' brechen kann, ist
unzulaenglich und somit auch unsinnig.
> In der Realität: Es gibt den Techniker(passt schon) und den
> Sicherheitsfanatiker(ui, das muss aber alles mindestens redundant sein) und
> den Jurist(wenn was passiert...) und den Wirtschaftler(billig muss es
> schein) und ... - das alles vernünftig unter einen Hut zu bringen ist
> schwer. Deshalb ist es gut Regeln aufzustellen die das Grundgerüst
> bilden.
Aus naheliegenden werden die technischen Anteile von
Reaktorsicherheitsbestimmungen *nicht* von Juristen, Wirtschaftlern,
Salesfraggles und Kabelziehern, die alle die Eigenschaft
'unqualifiziert' haben, untereinander ausgekungelt (vermutlich werden
sie das doch :->>).
Newsgroups: de.comp.lang.c
Von: Rainer Weikusat
Datum: Mon, 22 Mar 2004 05:08:03 +0100
Lokal: So 21 Mrz. 2004 23:08
Betreff: Re: MISRA-Standard Quellen?
"Herbert Rosenau" writes:
[...]
>> > Weikusat zeigt einmal mehr daß er nichts als Luftblasen produziert.
>> > Ahnung von dem über das er quasselt hat er jendenfall keine.
>> Woher willst du das wissen?
[...]
> Google nach weikusat.
>> Das ist vollkommener Bullshit. Produktqualitaet erreicht man nicht
>> durch drakonisches tyrannisieren der 'Produzierenden', sondern durch
>> eine Qualitaetskontrolle anhand objektiv ueberpruefbarer
>> Kriterien. Dazu zaehlt nicht subjektive Vorlieben irgendwelcher
>> Personen fuer ihre eigenen Geistesprodukte, wie zB projektierte
>> Programmierpsrachen, fuer die es noch nicht mal Compiler gibt.
> erzählt der Quatschkopp der ANSI für überflüssig hält.
'Scharfe Regeln' sind nicht dasselbe wie 'gründliche Kontrollen'.
Damit darfst Du Dich inhaltlich auseinandersetzen, falls Du dazu
imstande bist. Pöbeln kann jeder.
[...]
Das läuft immer noch darauf hinaus, daß alle Leute, die dieselben
Vorurteile haben wie Du, aus denselben Fakten identische
Schlußfolgerungen ziehen werden, es sich also erübrigt, im Detail
darauf einzugehen, *worauf* Du Dich eigentlich beziehst, weil alle,
'die des rechten Sinnes sind' ohnehin mit Dir übereinstimmen und alle
anderen das eben nicht sind.
Es stellt sich allerdings die Frage, warum etwas, das so
offensichtlich unsinnig ist (Deiner Meinung nach), wie das, was ich
geschrieben hatte, sich nicht auch einfachst sachlich widerlegen
lassen sollte. Es sollte das dann nämlich. Also bitte. Ich poste
nochmal ein stilmittelfreie Zusammenfassung, damit es auch für leicht
reizbare Leute etwas einfacher wird, den Kern der Aussage zu erkennen,
und nicht nur den Widerspruch als solchen.
1. Die Aussage 'wenn Menschenleben an einem winzigen Fehler hängen
können, können die Regeln nicht scharf genug sein' ist ein
Allgemeinplatz ohne Inhalt. Zum einen sind unsachliche Vorschriften
nicht deswegen 'scharf', weil sie unsachlich sind, sondern sie sind
genauso wie 'scharfe Regeln' (was auch immer das sein mag) auch
lästig, lediglich für eine andere Sorte von Leuten: 'Scharfe
Regeln' sind eine Belästigung für Leute, die gerne schlampen,
solange ihnen dafür niemand auf die Finger haut (Du redest von Dir?
Oder von Deinen Kollegen? Oder - in diesem Fall herzliches Beileid
an deren Adresse - von Untergebenen?). Unsachliche Regeln sind eine
Belästigung für Leute, die versuchen, ordentliche Arbeit zu
leisten. Eine 'scharfe Regel' in diesem Sinne wäre zum Beispiel die
Forderung, das grundsätzlich eine schriftliche Spezifikation
erstellt wird, und Implementierungen grundsätzlich brauchbar
dokumentiert werden. 'In der Praxis' scheitert die erste Forderung
daran, das diese auch niemand verstünde, der nicht auch mit der
Materie befaßt ist, nach Maßgabe der Abteilungen 'Vertrieb',
'Support' und 'Marketing' handelt es sich also um
Zeitverschwendung, die zu unterbleiben hat, wer es also nicht ohne
'kann', ist für seinen Job nicht ausreichend qualifiziert (ich
generalisiere meine Arbeitssituation, und während ich zum Glück
nicht für Menschenleben verantwortlich bin, könnte ich aber
mittelbar erhebliche finanzielle Verluste verursachen. Deswegen
wird mir aber trotzdem niemand freiwillig irgendwelche Zeit für
'Planung' zubilligen, erst recht nicht insofern das auch noch
Dritte 'vom Arbeiten abhalten würde'). Die Regel alleine bringt gar
nichts, solange sie nicht konsequent umgesetzt wird. Analog verhält
es sich mit dem zweiten Teil. Hierzu erlaube ich mir eine
Paraphrase eines Kollegen: 'Wenn ich wüßte, wie das geht, müßte ich
es am Ende noch selber tun', ergo: Keine Dokumentation. Sie wird
als Belästigung oder als 'sich ohne Grund wichtig machen'
empfunden, insbesondere von Leuten, die in einem der drei genannten
Bereiche arbeiten, denn es macht ihnen mehr Arbeit und 'es geht ja
auch so'. Die Forderung, kein if ohne else zu schreiben hingegen,
ist unsachlich. Nehmen wir mal folgendes Codebeispiel:
errno = 0;
ul = strtoul(s, &tail, 10);
if (errno) {
/* handle error */;
}
if (*s && *tail) {
/* invalid chars */;
}
/* everything is fine */
Es gibt hier keine 'else'-Zweige, an die man denken könnte,
ausser, dass die Grammatik welche erlauben würde. Also ändern wir
das mal so, um der Regel genüge zu tun:
errno = 0;
ul = strtoul(s, &tail, 10);
if (errno) {
/* handle error */
} else if (*s && *tail) {
/* invalid */;
} else {
/* do something */;
}
/* and now? */
Wird der Code dadurch irgendwie 'besser'? Meiner Meinung nach
nein. Also gut, nächster Versuch:
errno = 0;
ul = strtoul(s, &tail, 10);
if (!errno) {
if (!*s || !*tail) { /* 1 */
.
} else {
/* invalid */
}
/* and what goes here? */
} else {
/* error */
}
/* and here? */
1) Sowas haben wir doch hoffentlich alle im
Kopf, ja?
Oder direkt als Lippenbekenntnis:
errno = 0;
ul = strtoul(s, &tail, NULL);
if (errno) {
/* error */
} else ;
if (*s && *tail) {
/* invalid */
} else ;
Damit ist der Kontrollfluß wieder 'einfach' verständlich. Aber
welchen Sinn hat das? Antwort: Keinen. Es ist eine reine
Idiosynkrasie, die auswendig gelernt und mechanisch befolgt werden
muß 'weil das halt so ist'. Je mehr solcher 'unregelmäßiger
Verben' ich einem Menschen aufbürde, desto mehr intellektuelle
Kapazität muß dieser für immanent un-sinniges aufwenden. Keine
schlaue Strategie, falls man diese als begrenzt akzeptiert.
2. 'xy steigert die Sicherheit des Codes' ist eine Aussage ohne
Inhalt, denn es fehlt der Bezug: Was ist sicher vor wem oder
wer ist sich wessen sicher? Der Begriff ist nicht steigerbar:
Ich bin mir einer Tatsache entweder sicher, oder ich bin das
nicht. Ein Bremssystem, das nur in fünf von hundert Fällen
beschleunigt anstatt zu bremsen, ist nicht 'sicherer' als eines,
das das in dreißig von hundert fällen tut. Es bietet
statistisch größere Überlebenschancen, wird aber mit Sicherheit
zum Tode von irgendjemand führen, falls man es lange genug
darauf ankommen läßt, und eventuell schon beim ersten Mal.
Und jetzt möchte ich bitte mal etwas lesen, das sich nicht
ausschliesslich auf Gesetzesübertretungen beschränkt, Herr 'Scharfe
Regeln für Andere !!1'.
Newsgroups: de.comp.lang.c
Von: Rainer Weikusat
Datum: Mon, 22 Mar 2004 10:38:32 +0100
Lokal: Mo 22 Mrz. 2004 04:38
Betreff: Re: MISRA-Standard Quellen?
Bernd Nawothnig writes:
[...]
> Es ist natürlich in einigen hier mit Recht erwähnten Fällen
> illusorisch, eine perfekt angepasste Sprache zu erwarten. In solchen
> Fällen können Konventionen immerhin die Fehlerwahrscheinlichkeit
> reduzieren, wenn man gezwungen ist in einer für das Problem
> eigentlich ungeeigneten Sprache zu programmieren.
Es gibt einen durch nichts zu erschuetternden Glauben daran, das man
von einer bestimmten Personengruppe haeufig gemachten sprachlichen
Fehlern dadurch beikommen koenne, das man die Sprache um die
Konstrukte bereinigt, bei deren Verwendung in der Vergangenheit Fehler
gemacht wurden. Am besten illustiert ist das in '1984': Wenn die
Menschen nichts 'falsches' mehr denken koenne, weil sie keine Begriffe
mehr dafuer haben, denken sie nur noch 'richtig'. Das laesst allerdings
die Moeglichkeit kreativer Sprachnutzung vollkommen ausser acht,
sowohl, insoweit es Inhaltliches betrifft, als auch fuer
'Sprachfehlnutzung'. Das 'konventionelle' Verfahren (beim Erlernen
natuerlicher Sprachen) waere, problematische Konstrukte zu
trainieren. Von Fremdsprachenkorrespondenten wird erwartet, die
Sprache(n), in der/denen sie korrespondieren, zu erlernen. Warum nicht
auch von Programmierern?
>>> Selbst wenn manche Regeln von MISRA bei einem Release bewusst gebrochen
>>> werden -> wenn es begründet+logischerweise geschieht hat keiner was
>>> dagegen.
>> Eine 'Regel', die man 'logisch und begruendet' brechen kann, ist
>> unzulaenglich und somit auch unsinnig.
> Sie wird zumindest fragwürdig. So drastisch wie Du sehe ich das aber
> nicht.
Ich bin einfach nicht ueberzeugt davon, dass es hilfreich ist, Leute
dazu zu zwingen, sich Gedanken ueber Dinge zu machen, ueber die sie
sich Gedanken machen sollten.
Newsgroups: de.comp.lang.c
Von: Bernd Nawothnig
Datum: Mon, 22 Mar 2004 11:37:21 +0100
Lokal: Mo 22 Mrz. 2004 05:37
Betreff: Re: MISRA-Standard Quellen?
Hi Rainer,
On Mon, 22 Mar 2004, Rainer Weikusat wrote:
>> Es ist natürlich in einigen hier mit Recht erwähnten Fällen illusorisch,
>> eine perfekt angepasste Sprache zu erwarten. In solchen Fällen können
>> Konventionen immerhin die Fehlerwahrscheinlichkeit reduzieren, wenn man
>> gezwungen ist in einer für das Problem eigentlich ungeeigneten Sprache zu
>> programmieren.
> Es gibt einen durch nichts zu erschuetternden Glauben daran, das man von
> einer bestimmten Personengruppe haeufig gemachten sprachlichen Fehlern
> dadurch beikommen koenne, das man die Sprache um die Konstrukte bereinigt,
> bei deren Verwendung in der Vergangenheit Fehler gemacht wurden. Am besten
> illustiert ist das in '1984': Wenn die Menschen nichts 'falsches' mehr
> denken koenne, weil sie keine Begriffe mehr dafuer haben, denken sie nur
> noch 'richtig'. Das laesst allerdings die Moeglichkeit kreativer
> Sprachnutzung vollkommen ausser acht, sowohl, insoweit es Inhaltliches
> betrifft, als auch fuer 'Sprachfehlnutzung'. Das 'konventionelle'
> Verfahren (beim Erlernen natuerlicher Sprachen) waere, problematische
> Konstrukte zu trainieren. Von Fremdsprachenkorrespondenten wird erwartet,
> die Sprache(n), in der/denen sie korrespondieren, zu erlernen. Warum nicht
> auch von Programmierern?
Ich verstehe schon, was Du meinst und stimme Dir durchaus zu. Nun habe ich
aber auch schon diverse Programmierkurse geleitet oder betreut und da sind
gewisse Guidelines einfach besser, natürlich mit dem expliziten Zusatz, dass
es nur solche sind, da lege ich immer Wert drauf.
Aber speziell was das goto angeht, habe ich da im Zweifelsfall ähnlich
ketzerische Ansichten wie Du. Es ist Bestandteil der Sprache und darf
deswegen selbstverständlich verwendet werden. Allerdings empfehle ich
Anfängern, sich erstmal zu überlegen, ob man das Problem nicht anders und
dann auch besser verständlich formulieren kann. Betonung ist da auch immer,
den _Vorzug_ anderer Konstrukte zu zeigen.
Newsgroups: de.comp.lang.c
Von: Rainer Weikusat
Datum: Thu, 25 Mar 2004 21:09:29 +0100
Lokal: Do 25 Mrz. 2004 15:09
Betreff: Re: MISRA-Standard Quellen?
"Ralf Neuber" writes:
>> > Selbst wenn manche Regeln von MISRA bei einem Release bewusst gebrochen
>> > werden -> wenn es begründet+logischerweise geschieht hat keiner was
>> > dagegen.
>> Eine 'Regel', die man 'logisch und begruendet' brechen kann, ist
>> unzulaenglich und somit auch unsinnig.
> Hmm, glaube ich nicht ganz so. Manchmal kommt man in einer bestimmten
> Konstellation nur mit dem Brechen einer Regel zum Ziel. Dabei die Regel
> grundsätzlich gleich in frage stellen....
Ohne eine konkrete Regel hängt das etwas in der Luft, deswegen erlaube
ich mir mal ein Beispiel:
'Non-constant pointers to functions shall not be used' (Paraphrase).
Das läuft auf 'pointers to functions shall not be used' hinaus,
respektive darauf, eine strikte Unterscheidung zwischen 'passiven'
Daten und 'aktivem' Code zu haben. Falls ich irgendeine Form von OO
benutzen moechte (und ich moechte das), wuerde diese Regel das
untersagen. Ich kann jetzt 'begründet' darauf verzichten, aber dann
habe ich 'non constant pointer to functions shall only be used
where appropriate', was zwar sicher richtig ist, aber ein
Allgemeinplatz. Eine schoene Formulierung aus dem 'Camel book' (heute
Mittag auf der Arbeit gelesen): The optimizer makes no attempts to
move invariant code out of loops. It expects you *to exercise some
sense*.
Man sollte die Sinnhaftigkeit eigener Kreationen kritisch hinterfragen
obwohl es 'eigene' sind. Das bringt meiner Meinung nach mehr, als der
Versuch, 'Missgeburten' 'statisch' zu verhindern.
Newsgroups: de.comp.lang.c
Von: Bodo Thiesen
Datum: Sun, 21 Mar 2004 21:52:14 +0100
Lokal: So 21 Mrz. 2004 15:52
Betreff: Re: MISRA-Standard Quellen?
jos...@bigfoot.de (Jochen Schoof) wrote:
> Stefan Reuther wrote in message ...
>> 47 "No dependence should be placed on C's operator procedence(sic!)
>> rules in expressions"
>> (damit werden alle Ausdrücke verboten, die nicht die Form
>> 'a = b' oder 'a += b' haben, da ja 'a = b + c' sich darauf verläßt,
>> dass '+' einen geringeren Rang als '=' hat)
> MISRA sieht = offenbar nicht als Operator an, denn das Beispiel
> zur Anwendung von Regel 47 lautet "x = (3 * a) + (b / c);" :-)
Wir dürfen also zusammenfassen. Eine Gruppe von Leuten, die die Sprache C
nicht verstanden haben, stellen Richtlinien auf, was man (nicht) machen
muß/soll/darf, um möglichst "robusten" C-Code zu schreiben ...
>Lustiger sind meines Achtens einige Kombinationen von Regeln:
>1.) All code shall conform to ISO 9899 standard C, with no
> extenxsions permitted.
>9.) Comments shall not be nested.
>Doppelt genäht hält besser... ;-)
s.o. (das war mir nämlich auch gleich aufgefallen, und dürfte wiederum
Grund für Regel 10 "Sections of code should not be commented out" sein,
da in diesem Code-Bereich durchaus Kommentare liegen können.)
Witzig finde ich dann aber auch das Verbot von break und continue.
Gruß, Bodo
Newsgroups: de.comp.lang.c
Von: Stefan Reuther
Datum: Thu, 18 Mar 2004 22:36:50 +0100
Lokal: Do 18 Mrz. 2004 16:36
Betreff: Re: MISRA-Standard Quellen?
Herbert Rosenau wrote:
> On Thu, 18 Mar 2004 14:34:11 UTC, Stefan Reuther
>>Ansonsten sind da einige weitere seltsame Regeln drin:
>>10 "Sections of code should not be commented out"
>> (wie 'deaktiviert' man dann ein Stück Code?)
> #if 0
> #endif
[...]
> In sicherheitsrelevantem Code ist Klarheit wichtiger als Kompaktheit.
> ein
> if (x) blah();
> else ;
> kann einer Menge Überraschungen vorbeugen. Sieht zwar ziemlich
> unsinnig aus aber wehe dieser if wird in eine weitere Schatel gesteckt
Definiere "Klarheit".
Zu viele 'if' und zu viele Klammern sind auch wieder ungesund, weil man
dann vor lauter Rauschen nicht sieht, was der Code macht.
> Automatisierte Codeinspektion wird dadurch ein bißchen einfacher UND
> steigert die Sicherheit des Codes auch noch ein wenig. Man wird
> gezwungen an den else Zweig zu denken und den auch auszuformulieren -
> und wenn mit einem leeren statement. Dokumentiert daß man auch an die
> (überflüssige) Alternative gedacht hat.
Ich find's überflüssig. Bei Sachen wie
if (input_changed())
recompute_values();
brauche ich keinen else-Zweig. IMHO gewinnt man durch jene Regel nichts.
Die if/then/else-Mehrdeutigkeit tritt auch nicht auf, wegen "59 The
statements forming the body of an if, else if, else, while, do... while
or for statement shall always be enclosed in braces".
Newsgroups: de.comp.lang.c
Von: Bernd Nawothnig
Datum: Fri, 19 Mar 2004 03:24:09 +0100
Lokal: Do 18 Mrz. 2004 21:24
Betreff: Re: MISRA-Standard Quellen?
Hi Herbert,
On Thu, 18 Mar 2004 (UTC), Herbert Rosenau wrote:
> Wenn Menschenleben an einem winzigen Fehler hängen können, können
> Regeln nicht scharf genug sein.
Dann sollte dies bei der Wahl der Sprache bitte berücksichtigt werden. Es
ist unsinnig, mangelnde Restriktionen der Sprachdefinition durch
Codekonventionen ersetzen zu wollen und dieses dann als "Sicherheit" zu
bezeichnen. Siehe auch den absurden Vorschlag, alles zu klammern: wer
Operatoren und deren Vorrang für schwer verständlich oder abwegig hält,
sollte konsequenterweise auch eine funktionale Sprache wählen. Sowas gibt es
ja nun u.a. aus dem Grund.
From: Rainer Weikusat
Newsgroups: de.comp.lang.c
Subject: Re: clang V3.2
Date: Fri, 06 Jul 2012 15:55:52 +0100
Stefan Reuther writes:
> Naja..... Bei uns ist seit neuestem per ordre de mufti "-Wconversion"
> angeschaltet. Heißt: entweder, mann sieht in dem Wust vor Warnungen das
> Relevante in der Compilerausgabe nicht mehr, oder man sieht in dem Wust
> von Casts das Relevante im Code nicht mehr. Aber MISRA will's halt so.
Je nachdem wer wem einen Rat gibt oder zu geben versucht waere auch die
Ausgabe 'Beten Sie das Vaterunser' als 'moeglicherweise hilfreich'
anzusehen ...
http://www.c-plusplus.de/forum/203673-full
pointercrash()
Mitglied
Benutzerprofil
Anmeldungsdatum: 02.01.2005
Beiträge: 3058
Beitrag 11:26:41 26.01.2008 Titel:
Meine Erfahrungen mit MISRA sehen so aus:
In den frühen 90ern habe ich mal eine Bastelei abgeliefert, die im Wesentlichen
als Protokollumsetzer gearbeitet hat, das waren ein paar Zeilen Assembler
und weil's eine Insellösung war, hat sich niemand drum geschert.
Später wurde das Ding um einen weiteren Bus aufgestockt und ich hab's mit einem Pascal
neu gemacht, hat auch niemanden gejuckt.
Letztes Jahr mußte die Sache aus technischen Gründen nochmal erweitert
komplett neu designt werden, also in C, weil ein zugekaufter Netzwerkstack
integriert werden sollte.
Bei der Abnahme sagte man mir alles schön und gut, aber ist es auch MISRA- konform?
War mir völlig entgangen, aber Hausregel ist: Wenn C, dann nur MISRA.
Hätte ich Pascal genommen, wärs ihnen wurscht gewesen, dann hätte ich aber den Stack
selbst schreiben müssen.
Natürlich war's nicht konform. Nach dem Reformat- Lauf kommen einem manchmal
auch eigene Module seltsam vor, weil man's optisch einfach anders im Gedächtnis hat.
Natürlich wurden auch etliche Konstrukte bemängelt, die aber einwandfrei funktioniert
haben.
Eine Totalkatastrophe war dann auch noch die zugekaufte Lib, wenn fremder Code
MISRA- konform gemacht werden muß, muß man das ganze benörgelte Zeug auch verstehen.
Also der Umbau hat fast nochmal soviel Zeit gekostet wie das erste Design, ohne daß
das in irgendeiner Weise produktiv war oder bezahlt wurde.
Deswegen bin ich erstmal sauer auf das Beharren auf MISRA.
Ich bin seit 16 Jahren der Einzige, der an das Projekt hinpfuscht und wage zu behaupten,
daß die Anlage durch MISRA weder wartbarer geworden ist noch an Stabilität gewonnen hat,
an einigen Stellen sogar deutlich umständlicher.
Die Frage müßte lauten, ob es hier jemanden gibt, der sagt, fremden Code
kapier' ich viel schneller, wenn er MISRA- konform geschrieben ist, dann
hätte es einen Nutzen.