Tod durch Softwarefehler

[Hartmut Kraus]

Am 01.11.2013 11:43, schrieb Axel Berger:

Joerg wrote on Thu, 13-10-31 21:30:
sind kuerzer und/oder es vibriert dort nicht.

Es sind recht massive sinnvoll geformte Gußteile und überleben in allen
Fällen das Auto. Vibrieren tut's dort auch eher selten. 200 Mm in 20
Jahren sind bei 30 km/h 6700 h in 175000 h oder 96 % Ruhe.

Mit anderen Worten: Welches reine Privatfahrzeug ist eigentlich nicht
90% seiner Lebensdauer ein Stehzeug?

 

[Hartmut Kraus]

Am 01.11.2013 20:04, schrieb Stefan Reuther:

Aber sie verbieten immerhin, Code auszukommentieren,
Interessant und durchaus sinnvoll.

was wirksam unterbindet, dass der
Entwickler einer Funktion ein Verwendungsbeispiel in den Kommentar dazu
packt, weil dann das Validierungstool mault.

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.

 

[Rolf Bombach]

Eric Brücklmeier schrieb:

Am 28.10.2013 18:55, schrieb Gerrit Heitsch:
On 10/28/2013 06:46 PM, Bernd Laengerich wrote:
Am 28.10.2013 18:26, schrieb Gerrit Heitsch:

Was ist dann eine Landung nach der das Flugzeug direkt aus eigener Kraft
wieder starten kann?

Ist solch ein Vorkommen überliefert?

Ja, hier schon selbst gesehen:

http://de.wikipedia.org/wiki/Nationalpark_Canaima

Landebahn mitten im Dschungel, rundrum nur Wald. Dort mit einer 727
(kurze Version) gelandet, ausgestiegen und die gleich wieder weiter,
ohne auftanken (wie auch?).


Auch hier muß es klappen:

http://www.white-desert.com/wp-content/uploads/2012/06/8-Novo-runway-and-surrounding-buildings2.jpg

sogar mit sehr fettem Gerät (IL-76) - allerdings mit Auftanken...

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

--
mfg Rolf Bombach

 

[Sieghard Schicktanz]

Hallo Stefan,

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

[MISRA-C]

und bauen damit Fehler ein. Und dann bleibt an halbwegs unstrittigem nur
die Position der {}.

Hast Du Dich da nicht in der Notation geirrt? In C muß das doch wohl
eher "/*" und "*/" heißen, "{" und "}" sind doch die
Pascal-Kommentarklammern.

Ja und?

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

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.

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 waren
- 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
-----------------------------------------------------------

 

[Joerg]

Axel Berger wrote:

Joerg wrote on Thu, 13-10-31 21:30:
sind kuerzer und/oder es vibriert dort nicht.

Es sind recht massive sinnvoll geformte Gußteile und überleben in allen
Fällen das Auto. Vibrieren tut's dort auch eher selten. 200 Mm in 20
Jahren sind bei 30 km/h 6700 h in 175000 h oder 96 % Ruhe.

Bei mir war's so alle 15000km.

--
Gruesse, Joerg

http://www.analogconsultants.com/

 

[Rolf Bombach]

Stefan Huebner schrieb:

Ansonsten ist ECC-RAM bei Servern Standard und sollte es eigentlich auch
bei PCs sein. Wer schon einmal Stunden mit einem instabilen System
verbracht hat (memtest86+ findet nicht alles), der zahlt die paar Euro
extra für ECC-RAM mit Freuden.

Dazu kommen dann aber ein paar zehn Euro extra für ein Board mit Chipsatz, der ECC unterstützt. Ich habe es mehr zufällig in meiner Workstation - ein Quadcore
Xeon musste untergebracht werden
Aber absichtlich gekauft habe ich sowas bisher noch nie...

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

 

[Hartmut Kraus]

Am 01.11.2013 21:25, schrieb Joerg:

Axel Berger wrote:
Joerg wrote on Thu, 13-10-31 21:30:
sind kuerzer und/oder es vibriert dort nicht.

Es sind recht massive sinnvoll geformte Gußteile und überleben in allen
Fällen das Auto. Vibrieren tut's dort auch eher selten. 200 Mm in 20
Jahren sind bei 30 km/h 6700 h in 175000 h oder 96 % Ruhe.


Bei mir war's so alle 15000km.

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.

 

[Hartmut Kraus]

Am 02.11.2013 00:05, schrieb Hartmut Kraus:

Am 01.11.2013 21:25, schrieb Joerg:
Axel Berger wrote:
Joerg wrote on Thu, 13-10-31 21:30:
sind kuerzer und/oder es vibriert dort nicht.

Es sind recht massive sinnvoll geformte Gußteile und überleben in allen
Fällen das Auto. Vibrieren tut's dort auch eher selten. 200 Mm in 20
Jahren sind bei 30 km/h 6700 h in 175000 h oder 96 % Ruhe.


Bei mir war's so alle 15000km.
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.

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.

 

[Hartmut Kraus]

Am 02.11.2013 00:09, schrieb Hartmut Kraus:

Am 02.11.2013 00:05, schrieb Hartmut Kraus:
Am 01.11.2013 21:25, schrieb Joerg:
Axel Berger wrote:
Joerg wrote on Thu, 13-10-31 21:30:
sind kuerzer und/oder es vibriert dort nicht.

Es sind recht massive sinnvoll geformte Gußteile und überleben in allen
Fällen das Auto. Vibrieren tut's dort auch eher selten. 200 Mm in 20
Jahren sind bei 30 km/h 6700 h in 175000 h oder 96 % Ruhe.


Bei mir war's so alle 15000km.
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.

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.
Hier nur eins der Suchergebnisse ("BMW Hinterachse Konstruktionsfehler"):

http://www.auto-fachforum.de/bmw-e46-riss-hinterachse-t112.html

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

 

[Hartmut Kraus]

Am 01.11.2013 21:25, schrieb Sieghard Schicktanz:

(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 waren
- bis mir aufgefallen isat, daß ich grade nicht ein Pascal- sondern ein
C-Programm angeschaut habe...)
Das glaube ich dir, wenn ich den Code mal gesehen habe.

 

[Hartmut Kraus]

Am 01.11.2013 21:44, schrieb Rolf Bombach:

Stefan Huebner schrieb:

Ansonsten ist ECC-RAM bei Servern Standard und sollte es eigentlich auch
bei PCs sein. Wer schon einmal Stunden mit einem instabilen System
verbracht hat (memtest86+ findet nicht alles), der zahlt die paar Euro
extra für ECC-RAM mit Freuden.

Dazu kommen dann aber ein paar zehn Euro extra für ein Board mit
Chipsatz, der ECC unterstützt. Ich habe es mehr zufällig in meiner
Workstation - ein Quadcore
Xeon musste untergebracht werden
Aber absichtlich gekauft habe ich sowas bisher noch nie...

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...
Und wer kauft sowas?

 

[Eric Brücklmeier]

Am 01.11.2013 20:48, schrieb Rolf Bombach:

Eric Brücklmeier schrieb:
Am 28.10.2013 18:55, schrieb Gerrit Heitsch:
On 10/28/2013 06:46 PM, Bernd Laengerich wrote:
Am 28.10.2013 18:26, schrieb Gerrit Heitsch:

Was ist dann eine Landung nach der das Flugzeug direkt aus eigener
Kraft
wieder starten kann?

Ist solch ein Vorkommen überliefert?

Ja, hier schon selbst gesehen:

http://de.wikipedia.org/wiki/Nationalpark_Canaima

Landebahn mitten im Dschungel, rundrum nur Wald. Dort mit einer 727
(kurze Version) gelandet, ausgestiegen und die gleich wieder weiter,
ohne auftanken (wie auch?).


Auch hier muß es klappen:

http://www.white-desert.com/wp-content/uploads/2012/06/8-Novo-runway-and-surrounding-buildings2.jpg


sogar mit sehr fettem Gerät (IL-76) - allerdings mit Auftanken...

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

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.

 

[Stefan Reuther]

Hartmut Kraus wrote:

Am 01.11.2013 20:04, schrieb Stefan Reuther:
Aber sie verbieten immerhin, Code auszukommentieren,

Interessant und durchaus sinnvoll.

was wirksam unterbindet, dass der
Entwickler einer Funktion ein Verwendungsbeispiel in den Kommentar dazu
packt, weil dann das Validierungstool mault.

Nö. Ein Verwendungsbeispiel wäre meinetwegen "z = MeineFunktion (x, y)"
mit konkreten Werten für die Parameter und den Rückgabewert.

Das ist eine Zeile Code.

> Dazu braucht's doch keine 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

 

[Hartmut Kraus]

Am 02.11.2013 18:34, schrieb Stefan Reuther:

Hartmut Kraus wrote:
Am 01.11.2013 20:04, schrieb Stefan Reuther:
Aber sie verbieten immerhin, Code auszukommentieren,

Interessant und durchaus sinnvoll.

was wirksam unterbindet, dass der
Entwickler einer Funktion ein Verwendungsbeispiel in den Kommentar dazu
packt, weil dann das Validierungstool mault.

Nö. Ein Verwendungsbeispiel wäre meinetwegen "z = MeineFunktion (x, y)"
mit konkreten Werten für die Parameter und den Rückgabewert.

Das ist eine Zeile Code.
Das ist eine Zeile Kommentar.

Dazu braucht's doch keine 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.
Dann ist das Quatsch.

 

[Heinz Saathoff]

Stefan Reuther schrieb...

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.

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

 

[Bernd Laengerich]

Am 04.11.2013 13:14, schrieb Heinz Saathoff:

> Warum nicht alle Kommentare in ROT-13 schreiben? Fehlt nur noch eine

Weil code als solcher immer noch strukturell code bleibt.

Aus
* if (x>0 && y<10) {
* int i = dosomething(x,y);
* }
wird
* vs (k>0 && l<10) {
* vag v = qbfbzrguvat(k,l);
* }

Das sieht code strukturell schon sehr ähnlich, der Parser wird vermutlich
nicht unbedingt prüfen, daß vag kein definierter Typ und qbfbzrguvat keine
definierte Funktion ist.

Bernd
--
Meine Glaskugel ist mir leider unvorhersehbarerweise vom Balkon gefallen.
P.Liedermann in defa

 

[Hartmut Kraus]

Am 04.11.2013 13:14, schrieb Heinz Saathoff:

Stefan Reuther schrieb...

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.

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.

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

 

[Axel Berger]

Heinz Saathoff wrote on Mon, 13-11-04 13:14:
>Warum nicht alle Kommentare in ROT-13 schreiben?

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.

 

[Stefan Reuther]

Heinz Saathoff wrote:

Stefan Reuther schrieb...
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.

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.

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

 

[Gerrit Heitsch]

On 11/01/2013 08:41 PM, Hartmut Kraus wrote:

Am 01.11.2013 20:04, schrieb Stefan Reuther:
Aber sie verbieten immerhin, Code auszukommentieren,
Interessant und durchaus sinnvoll.

Sehe ich anders. Kommentare sollen den Code erklären und manchmal geht
das eben mit einem kurzen Stück Code der eine Verwendung erklärt besser
als mit 5 Seiten Text.

Problem ist natürlich die Abwesenheit von geschachtelten Kommentaren in
C und das man // nicht verwenden darf (warum auch immer), damit ist das
auskommentieren von kommentiertem Code fehlerträchtig. Aber es würde
reichen auf diesen Fall zu testen und nicht einfach das Auskommentieren
von Code zu verbieten.

Alternativ lässt man den Code vor Validierung und Compilation durch
einen Kommentar-Stripper laufen.

Gerrit