Tod durch Softwarefehler

Ja und?

MISRA-C schreibt vor, wo { } zu verwenden sind.

Wo /* */ zu verwenden ist, schreiben sie nicht vor. Aber sie verbieten immerhin, Code auszukommentieren, was wirksam unterbindet, dass der Entwickler einer Funktion ein Verwendungsbeispiel in den Kommentar dazu packt, weil dann das Validierungstool mault.

Stefan

Reply to
Stefan Reuther
Loading thread data ...

Am 01.11.2013 11:43, schrieb Axel Berger:

Mit anderen Worten: Welches reine Privatfahrzeug ist eigentlich nicht

90% seiner Lebensdauer ein Stehzeug?
Reply to
Hartmut Kraus

Am 01.11.2013 20:04, schrieb Stefan Reuther:

Interessant und durchaus sinnvoll.

Nö. Ein Verwendungsbeispiel wäre meinetwegen "z = MeineFunktion (x, y)" mit konkreten Werten für die Parameter und den Rückgabewert. Dazu braucht's doch keine Zeile Code.

Reply to
Hartmut Kraus

Eric Brücklmeier schrieb:

In diesem Umfeld würde ich die Motoren ganz sicher nicht abstellen.

--
mfg Rolf Bombach
Reply to
Rolf Bombach

Hallo Stefan,

Du schriebst am Fri, 01 Nov 2013 20:04:43 +0100:

[MISRA-C]

hl

Nach Deinen Ausführungen blieben dann meiner Auffassung nach praktisch nur mehr die Kommentare als frei definierbare Elemente übrig.

Aber nach der Angabe sind ja noch nichtmal Kommentare unreglementiert.

(BTW, auf meine Bemerkung gekommen bin ich, weil ich immer mal wieder mit beidem zu tun habe und mich einmal beim Suchen nach der Programmlogik gewundert habe, warum die eigentlich nötigen Befehle auskommentiert wa ren

- bis mir aufgefallen isat, daß ich grade nicht ein Pascal- sondern ein C-Programm angeschaut habe...)

--
--  
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung 
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem) 
----------------------------------------------------------- 
Mit freundlichen Grüßen, S. Schicktanz 
-----------------------------------------------------------
Reply to
Sieghard Schicktanz

Bei mir war's so alle 15000km.

--
Gruesse, Joerg 

http://www.analogconsultants.com/
Reply to
Joerg

Stefan Huebner schrieb:

Dito. Eine deutsche Firma mit gewisser Tendenz zu, sagen wir mal schwammiger, Software versucht seit einigen Jahren, das durch Verwenden von Dual-Xeon-Serverboards zu "verbessern". Immerhin schütteln die Leute dort an der Basis den Kopf über diesen Chef-Entscheid. Zur Kiste mein Eindruck: Da die technisch hinter den Desktopprozessoren zurückliegen, sind die langsam. Und einen "netten" Stromverbrauch haben die auch. Der ganze Rechner: 185 W Leerlauf, 260 W bei LTspice auf allen 8 Kanälen...

--
mfg Rolf Bombach
Reply to
Rolf Bombach

Würde mich ja langsam mal interessieren, wie das Teil aussah. Und welches Problem es mit ein bisschen handwerklichem Geschick gewesen sein sollte, die Stelle, an der's brach, ein bisschen zu verstärken.

Reply to
Hartmut Kraus

Am 02.11.2013 00:05, schrieb Hartmut Kraus:

Wie die erwähnte Achsaufhängung beim BMW - da hatte auch jede Werkstatt so ihre "Methoden". Aber eben solche: "Wie vermeide ich Rumgemaule vom Kunden über die Schraubenköpfe (oder Schweißnähte?) im Kofferraumboden statt einer angetriebenen Hinterachse, die ihn irgendwann selber überholt" - so etwa.

Reply to
Hartmut Kraus

Am 02.11.2013 00:09, schrieb Hartmut Kraus:

Hier nur eins der Suchergebnisse ("BMW Hinterachse Konstruktionsfehler"):

formatting link

"Kulanzantrag" - das war ja wohl der Witz in Tüten, oder?

Reply to
Hartmut Kraus

Am 01.11.2013 21:25, schrieb Sieghard Schicktanz:

Das glaube ich dir, wenn ich den Code mal gesehen habe.

Reply to
Hartmut Kraus

Am 01.11.2013 21:44, schrieb Rolf Bombach:

Und wer kauft sowas?

Reply to
Hartmut Kraus

Am 01.11.2013 20:48, schrieb Rolf Bombach:

Machen sie aber, manchmal bleibt das Gerät wetterbedingt auch länger stehen.

Aber es gibt auch Situationen (z.B. Eröffnung der Kohnen Sommerstation) da bleibt der Pilot erstmal mit laufenden Motoren sitzen und wartet, ob die Jungs bei -40°C den Diesel zum Laufen bringen - denn auf dem Landweg braucht man eine Woche dorthin und zu der Zeit sind häufig noch keine anderen Flugzeuge verfügbar, die dort landen könnten.

Reply to
Eric Brücklmeier

Das ist eine Zeile Code.

Das ist egal. Das Validierungstool hat eine Heuristik dafür, was Code sein könnte. Und wenn dein Kommentar so aussieht, als ob er welchen enthielte, mault es.

Und dann fängt man eben an, seinen Code zu verstümmeln. Punkte statt Semikolons, runde statt geschweifter Klammern. Ungefähr so wie die Spaßvögel, die Emailadressen zu schützen versuchen, indem sie (at) statt @ schreiben.

Unter produktivem Arbeiten stell ich mir anderes vor.

Stefan

Reply to
Stefan Reuther

Das ist eine Zeile Kommentar.

Dann ist das Quatsch.

Reply to
Hartmut Kraus

Stefan Reuther schrieb...

statt

Warum nicht alle Kommentare in ROT-13 schreiben? Fehlt nur noch eine Editor, der das automatisch hin und her kodiert, und schon gibt's dieses Problem nicht mehr.

- Heinz

Reply to
Heinz Saathoff

Am 04.11.2013 13:14, schrieb Heinz Saathoff:

Weil code als solcher immer noch strukturell code bleibt.

Aus * if (x>0 && y0 && l

Reply to
Bernd Laengerich

Am 04.11.2013 13:14, schrieb Heinz Saathoff:

Ein Problem, das man sich erst selber geschaffen hat - im Sinne der Sicherheit hoffentlich nur in Ermangelung echter Probleme.

Reply to
Hartmut Kraus

Heinz Saathoff wrote on Mon, 13-11-04 13:14:

Weil das, wie der Name schon andeutet, nur Buchstaben tauscht und keine Satzzeichen und damit den Zweck völlig verfehlt. ROT18 ginge vielleicht ist aber weit weniger verbreitet. Und ein nicht direkt menschenlesbarer Kommentar ist ohnehin eher sinnlos.

Reply to
Axel Berger

base64 würde helfen, rot13 ändert nichts daran, dass Zeilen mit Häufungen von (){}; angemeckert werden.

Einen Kommentar "vpu oerzfr avpug shre ZVFEN" findet man zumindest in irgendeinem älteren Modul von mir, als Anmerkung zu einem goto oder so.

Stefan

Reply to
Stefan Reuther

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.