for(;;) bedeutung?

Kann mir jemand erklären wie das aus dem Standard gelesen werden kann? 
Ein leeres Statement evaluiert doch nicht immer zu wahr, oder?

C99:
6.8.5.3 The for statement
[...]
for ( clause-1 ; expression-2 ; expression-3 ) statement
[...]
Both clause-1 and expression-3 can be omitted. An omitted expression-2 
is replaced by a nonzero constant.

physiker schrieb:
> Das man die Laufzeitvaribel und Abbruchbedingung undefiniert lässt. Ist
> eine (IMHO etwas konfuse) Art eine Endlosschleife zu definieren.

Gibt's denn eine weniger konfuse? Bei while muss man immer eine 
Pseudo-Bedingung hinschreiben, während man bei for die Bedingung einfach 
weglassen kann, wenn man keine hat.

Rolf M. schrieb:
> physiker schrieb:
>> Das man die Laufzeitvaribel und Abbruchbedingung undefiniert lässt. Ist
>> eine (IMHO etwas konfuse) Art eine Endlosschleife zu definieren.
>
> Gibt's denn eine weniger konfuse? Bei while muss man immer eine
> Pseudo-Bedingung hinschreiben, während man bei for die Bedingung einfach
> weglassen kann, wenn man keine hat.

Vor allem weiß man bei for(;;), dass der Schreiberling auch wirklich 
eine Endlosschleife haben will. Bei while kann es auch ein Versehen 
sein, wegen der Pseudobedingung. Ist alles schon mal vorgekommen...

Deshalb nehme ich lieber for(;;).

Christopher C. schrieb:
> Vor allem weiß man bei for(;;), dass der Schreiberling auch wirklich
> eine Endlosschleife haben will. Bei while kann es auch ein Versehen
> sein, wegen der Pseudobedingung. Ist alles schon mal vorgekommen...
>
> Deshalb nehme ich lieber for(;;).

Echt? mit while(true) bist du überfordert?

Hannes J. schrieb:
> Echt? mit while(true) bist du überfordert?

Naja, am Ende steht oben irgendwo:
#define true 0

Stefan U. schrieb:
> For Schleifen laufen ja so lange, wie der dritte Ausdruck in
> den Klammern true ist.

Ich würde es vorziehen, wenn es der zweite wäre.

> Und nichts ist immer true, also Endlosschleife.

Weil per Standard so festgelegt.

Stefan U. schrieb:
> For Schleifen laufen ja so lange, wie der dritte Ausdruck in
> den Klammern true ist.

Das ist wie bei Milli Vanilli:

Girl, you know it's true.

MfG Paul

Hannes J. schrieb:
> Christopher C. schrieb:
>> Vor allem weiß man bei for(;;), dass der Schreiberling auch wirklich
>> eine Endlosschleife haben will. Bei while kann es auch ein Versehen
>> sein, wegen der Pseudobedingung. Ist alles schon mal vorgekommen...
>>
>> Deshalb nehme ich lieber for(;;).
>
> Echt? mit while(true) bist du überfordert?

Du willst mich falsch verstehen, oder?

Wolfgang schrieb:
> Mathias schrieb:
>> was bedeuten die zwei Semikolon in der Klammer: for(;;) ??
>
> Vermutlich weisst du auch, dass das C-Code ist.
>
> Du darfst eine for-Schleife in C nicht mit for-Schleifen in anderen
> Programmiersprachen verwechseln. In anderen Sprachen wird die Anzahl der
> Durchläufe zusammen mit dem Schlüsselwort FOR festgelegt, d.h. die
> Schleife wird unabhängig von dem, was in der Schleife passiert, eine
> vordefinierte Anzahl von Durchläufen abgearbeitet.

Ich würde hier nicht so pauschal von "anderen Programmiersprachen" 
sprechen. In mehreren Sprachen ist es so wie in C. In manchen ist es 
nochmal ganz anders. In Python z.B. iteriert man mit einer for-Schleife 
durch eine Sequenz. Eine Zählschleife, wie du sie beschreibst, gibt es 
da gar nicht.

bastel_ schrieb:
> Ich bin ja auch für while ( true ). Ist einfach sauberer.

Was soll denn daran sauberer sein, bei einer Schleife, für die man keine 
Bedingung hat, trotzdem eine hinschreiben zu müssen? Die Frage ist ernst 
gemeint. Ich möchte es wirklich gerne verstehen, denn für mich ist eben 
aus dem genannten Grund das for sauberer, da es direkter ausdrückt, 
was ich will - nämlich eine Schleife ohne Bedingung.

Über Geschmack lässt sich [nicht] streiten.

In Assembler gibt's bedingte Sprünge und unbedingte. Wenn man damit eine 
Endlosschleife machen will, käme aber keiner auf die Idee erst manuell 
ein Flag zu setzen, dann direkt danach mit einem bedingten Sprung zu 
prüfen, ob es gesetzt ist und dann springen. Man würde einfach einen 
unbedingten Sprung hinschreiben. while(true) ist für mich das C-Pendant 
zu ersterem, for(;;) das zu zweiterem.

mh schrieb:
> Und die saubere Schreibweise für eine Schleife deren Bedingung immer
> erfüllt ist, ist while(true).

true ist für mich keine richtige Bedingung, da es von nichts abhängt. 
Dehsalb hatte ich es oben als Pseudobedingung bezeichnet.
Umgangssprachlich würde ich ja auch eher sagen "tue xyz, ohne je 
abzubreuchen" und nicht "tue xyz, solange wahr wahr ist".

Rolf M. schrieb:
> käme aber keiner auf die Idee erst manuell
> ein Flag zu setzen, dann direkt danach mit einem bedingten Sprung zu
> prüfen, ob es gesetzt ist und dann springen.

Sowas ergab bei Transputern mitunter einen Sinn. Deren unbedingter 
Sprung konnte den 3-Register-Stack wegfegen, was der bedingte Sprung 
nicht tat. Folglich gab es Fälle, in denen man damit besser dran war als 
mit dem unbedingten Sprung:
   ldc 0  // push 0
   cj L   // jump if TOS=0
   ...
L: add    // remove the 0

mh schrieb:
> Dann würdest du auch eher
> bool flag;
> ...
> irgendwas passiert mit flag
> ...
> if(flag == true){...}
> statt
> if(flag){...}
> schreiben?

Nein, wie kommst du darauf?

c-hater schrieb:
> aber für das zweite void als
> völlig sinnentleerten Parameter gibt es schlicht keine Entschuldigung
> und keine Ausrede.

Eine historische gibt es. Vor C89 gab es in C bei Funktionsdeklarationen 
keine Parameterdeklarationen. f() war also ein Funktion mit unbekannter 
Anzahl von Parametern unbekannten Typs. Um die Kompatibilität mit altem 
Code nicht zu verlieren musste f(void) her. Das muss man natürlich nicht 
schön finden.

C++ hat damit aufgeräumt, weil die Kompatibilitätsforderung darin nicht 
mehr gegeben war.

> Insbesondere nicht unter dem Aspekt, das ein "void *"
> schon wieder was völlig anderes bedeutet,

Vor C89 gab es keinerlei "void" und die Anzahl Schlüsselwörter wollte 
man nicht beliebig aufblähen - wieder um alte Programme nicht unnötig zu 
behindern.

c-hater schrieb:
> Wenn das nicht vollkommen krank ist, was denn sonst? In sinnvollen
> Sprachen wird das erste void überflüssig durch Einführung eines
> besonderen Schlüsselworts für eine Funktion ohne Result

Du willst also das Schlüsselwort, mit dem man in C angibt, dass eine 
Funktion nichts zurückgibt, durch ein Schlüsselwort ersetzen, mit dem 
man angibt, dass die Funktion nichts zurückgibt? Mir erschließt sich der 
Unterschied nicht.

> (ich könnte noch verstehen, wenn man darauf verzichtet) aber für das
> zweite void als völlig sinnentleerten Parameter gibt es schlicht keine
> Entschuldigung und keine Ausrede.

Das ist tatsächlich der Historie und der Kompatibilität zu "früher(tm)" 
geschuldet. In C++ braucht man es dann auch nicht, wobei es optional 
immer noch erlaubt ist - ebenfalls aus Kompatibilitätsgründen.

> Krank, pervers, vollkommen lächerlich. Aber immer noch in Benutzung,
> Jahrzehnte nachdem die Zwänge weggefallen sind, die mal solche Lösungen
> erfordert haben...

Nebenan im Python-Thread beschweren sich manche, dass man die Frechheit 
besessen hat, von Python 2 zu Python 3 die Kompatibilität zu brechen, du 
beschwerst dich, dass C so viele Altlasten mit sich rumschleppt. Man 
kann's halt nicht jedem recht machen.

Nop schrieb:
> Wenn man ein wenig trollen wollte, könnte man natürlich auch in C ein
> Label am Schleifenanfang setzen, zu dem man am Schleifenende dann mit
> GOTO springt.

YMMD :-D

sowaresmal schrieb:
> Optimierende Compiler gab es früher nicht. Deshalb erzeugte while(1)
> immer einen Test mit Verzweigung.

Solche Optimierungen sind kinderleicht, viel einfacher als Optimierung 
von Registernutzung. Weshalb das schon um 1980 herum in C kein Problem 
war.

Rene K. schrieb:
> YMMD :-D

Wobei eine Umstellung der bedingten Schleife auf den Test am Ende damals 
ebenso wenig ein Problem war.
   while(cond) ...
lässt sich trivial als
   jump L
M: ...
L: cond jump M
erzeugen. Und da Konstanten und konstante Ausdrücke in einem C Compiler 
ohnehin schon immer eine Sonderstellung hatten, war die Ersetzung 
eines bedingten durch einen unbedingten Sprung am Ende trivial.

c-hater schrieb:
> Rolf M. schrieb:
>
>> Du willst also das Schlüsselwort, mit dem man in C angibt, dass eine
>> Funktion nichts zurückgibt, durch ein Schlüsselwort ersetzen, mit dem
>> man angibt, dass die Funktion nichts zurückgibt? Mir erschließt sich der
>> Unterschied nicht.
>
> Ganz einfach: Eine Funktion, die nichts zurückgibt, ist keine Funktion,
> zumindest nicht im mathematischen Sinn. Entprechende Sprachkonstrukte
> sollten also auch nicht so heißen.

In imperativen Sprachen sind die wenigsten Funktionen wirklich 
Funktionen im mathematischen Sinne, denn ein ganz wesentliches Element 
sind die "side effects", die den Zustand des Programms ändern. Sowas 
gibt es in mathematischen Funktionen nicht. Und streng genommen geben 
C-Funktionen nicht nichts zurück. void ist ein Datentyp, allerdings sein 
so genannter unvollständiger (ähnlich wie z.B. ein nur deklarierter, 
aber nicht definierter Strukturtyp), d.h. sein Aufbau und Inhalt gelten 
als unbekannt. Und im Prinzip gibt die Funktion dann eben ein Objekt vom 
Typ void zurück. Da er unvollständig ist, kann ich aber nicht selbst ein 
Objekt dieses Typs anlegen und den Rückgabewert diesem zuweisen.

> Bedenklich bei C (und seinen syntaktischen Erben) ist halt die völlig
> willkürliche Bedeutung des "void"-Schlüsselworts in Abhängigkeit vom
> Kontext, die die einfache Lösung (nämlich "void function" einfach als
> ein Schlüsselwort zu betrachten) leider unmöglich macht.

Bis auf Funktionsparameter, wo das void tatsächlich anders verwendet 
wird, ist die Bedeutung eigentlich immer gleich. Auch ein void* ist 
einfach nur ein Zeiger auf den unvollständigen Typ void.

> Das ist übrigens nicht nur für Menschen ein Problem, sondern auch für
> den Compiler. Es hält ihn u.U. zumindest davon ab, für ein konkret
> erkanntes syntaktisches Problem eine sinnvolle und zielführende
> Fehlermeldung für den Programmierer liefern zu können...

Generell macht es die Erstellung eines Compilers aufwändiger. Deshalb 
versucht man heutzutage, in Sprachen Kontextabhängigkeiten möglichst 
gering zu halten.

> Solche Probleme liefern auch andere sinnlosen Mehrfachnutzungen von
> Schlüsselwörtern. Sehr deutlich zu bemerken z.B. bei "static" in C++...

Das ist auch in C schon so.

> Dieselbe Wurzel, dieselbe Seuche. Gespart an Sachen, bei denen überhaupt
> kein Sparzwang besteht...

Man versucht bei so langlebigen Sprachen, die Zahl der Schlüsselwörter 
gering zu halten, da jedes neue Schlüsselwort mehr alte Programme 
inkompatibel macht. Deshalb wird mit diesen in C (und auch in C++) 
besonders sparsam umgegangen - manchmal vielleicht etwas übertrieben, 
aber allgemein trotzdem sinnvoll.

c-hater schrieb:
> Ganz einfach: Eine Funktion, die nichts zurückgibt, ist keine Funktion,
> zumindest nicht im mathematischen Sinn. Entprechende Sprachkonstrukte
> sollten also auch nicht so heißen.

Da C keine Schlüsselworte für Funktion vs. Prozedur hat, aber auch 
Rechenausdruck und Zuweisung nicht unterschiedlich klassifiziert sind, 
fehlt dieser formellen Unterscheidung schlicht die Grundlage. Das ist in 
Sprachen der Algol/Pascal-Tradition anders - und lesbarer.

Es ist aber müssig, sich heute um solche semantische Feinheiten zu 
streiten. Diese Entscheidung fiel in den 60ern. Es gibt in C so einige 
Dinge, die man im Nachhinein betrachtet besser machen könnte.

Aber gerade diese fehlende formelle Unterscheidung zwischen Funktion und 
Prozedur bietet für mich wenig Anlass für ernste Kritik. Ich kann ganz 
gut damit leben. Ob man schreibt:
  p: procedure(integer);
  f: function(integer) returning integer;
oder (wie es in C besser gewesen wäre):
  p: (int);
  f: (int) int;
ist nur eine Frage von ausführlicher schlüsselwortbetonter Formulierung 
gegenüber knapper Kurzform, aber kein grundsätzlicher Unterschied. Das 
Problem in C ist, dass es leider auch nicht wie diese Kurzform aussieht.

> Bedenklich bei C (und seinen syntaktischen Erben) ist halt die völlig
> willkürliche Bedeutung des "void"-Schlüsselworts in Abhängigkeit vom
> Kontext, die die einfache Lösung (nämlich "void function" einfach als
> ein Schlüsselwort zu betrachten) leider unmöglich macht.

So arg unterschiedlich ist die Bedeutung nicht. "void" steht sinngemäss 
für "nichts", und das passt für alle Formen, wie
  void f(int);   // 1 gibt nichts zurück
  int h(void);   // 2 hat keine Parameter
  void *p;       // 3 zeigt auf keinen Typ
  (void) f(1);   // 4 wirft Ergebnis ins Nichts
Weshalb 2 so aussieht hatte ich schon erwähnt. h() wäre besser gewesen, 
ging aber nicht mehr.

> Das ist übrigens nicht nur für Menschen ein Problem, sondern auch für
> den Compiler. Es hält ihn u.U. zumindest davon ab, für ein konkret
> erkanntes syntaktisches Problem eine sinnvolle und zielführende
> Fehlermeldung für den Programmierer liefern zu können...

Yep. Der Parser einer schüsselwortbetonten Sprache merkt schneller, dass 
er auf dem Holzweg ist, als der Parser einer Sprache, in der fast alles 
irgendwie Sinn ergeben könnte und es erst eine halbe Zeile später 
offenkundig wird. Ein Problem auch von Sprachen ohne reservierte 
Schlüsselworte, wie Fortran oder PL/I.

Stefan U. schrieb:
> Mit for() assoziiere ich eine Wiederholschleife, bei der eine
> Zählvariable hoch oder runter gezählt wird. Das ist in C zwar nicht die
> einzige vorgesehene Anwendung, aber zweifellos die häufigste.

Das ist nun allerdings dein eigenes spezifisches Problem. Vielleicht 
geprägt durch BASIC? (siehe Nachbarthread über die Erstsprache)

Wenn man es etwas abstrakter als Statement für Iteration sieht, dann hat 
man auch kein Problem mit
   for (p = root; p; p = p->next)
und allerlei höheren Varianten in C++. Dazu kommt dann noch, dass man 
(heute) mit
   for (T *p = root; p; p = p->next)
eine übersichtliche Klammer für den Scope von p gleich mit dabei hat.

Mal ketzerisch in die andere Richtung:

Warum soll es einen speziellen, mit eigenem Schlüsselwort versehenen 
Funktionstyp geben, der sich von anderen nur dadurch unterscheidet, daß 
er einen ganz bestimmten Typ, ein "nichts", als Rückgabewert hat?

Braucht man dann nicht auch
[Unsigned][Long]IntFunction(),
[Long]DoubleFunction() oder
CharPointerArrayOfNineReferenceFunction()?

Es gäbe viel zu hassen, wenn sich jemand so blöd gestellt hätte, es zu 
erfinden.

A. K. schrieb:
> c-hater schrieb:
>> Ganz einfach: Eine Funktion, die nichts zurückgibt, ist keine Funktion,
>> zumindest nicht im mathematischen Sinn. Entprechende Sprachkonstrukte
>> sollten also auch nicht so heißen.
>
> Da C keine Schlüsselworte für Funktion vs. Prozedur hat, aber auch
> keinen syntaktischen Unterschied zwischen Rechenausdruck und Zuweisung,
> fehlt dieser formellen Unterscheidung schlicht die Grundlage. Das ist in
> Sprachen der Algol/Pascal-Tradition anders - und lesbarer.

Ich habe Pascal vor C gelernt und mich damals gefragt, warum man zwei 
Dinge, die - abgesehen davon, dass eins einen Wert zurückgibt und das 
andere nicht - genau das selbe sind, komplett unterschiedlich benennt.

> Yep. Der Parser einer schüsselwortbetonten Sprache merkt schneller, dass
> er auf dem Holzweg ist, als der Parser eine Sprache, in der fast alles
> irgendwie Sinn ergeben könnte und es erst eine halbe Zeile später
> offenkundig wird. Ein Problem auch von Sprachen ohne reservierte
> Schlüsselworte, wie Fortran oder PL/I.

Lustig ist das bei Sprachen, in denen z.B. Leerzeichen Teil von 
Identifiern sein dürfen. Oder welche, in denen Identifier auch gleich 
heißen dürfen wie Schlüsselwörter. Das gab es alles mal.

Carl D. schrieb:
> Mal ketzerisch in die andere Richtung:
>
> Warum soll es einen speziellen, mit eigenem Schlüsselwort versehenen
> Funktionstyp geben, der sich von anderen nur dadurch unterscheidet, daß
> er einen ganz bestimmten Typ, ein "nichts", als Rückgabewert hat?

Und braucht man dann für eine "Funktion", die keine Parameter hat, noch 
einen weiteren Namen? Und nochmal einen für etwas, das weder Parameter 
noch einen Rückgabewert hat?

Heiner schrieb im Beitrag #4747898:
> hier wird nur noch rumgetrollt.

Eigentlich nur von dir. Wo kommst du denn plötzlich her?

Carl D. schrieb:
> Warum soll es einen speziellen, mit eigenem Schlüsselwort versehenen
> Funktionstyp geben, der sich von anderen nur dadurch unterscheidet, daß
> er einen ganz bestimmten Typ, ein "nichts", als Rückgabewert hat?
>
> Braucht man dann nicht auch
> [Unsigned][Long]IntFunction(),
> [Long]DoubleFunction() oder
> CharPointerArrayOfNineReferenceFunction()?

Nein. Es ist der Unterschied zwischen einer Funktion
  f: function (...) returning unsigned long int; // oder double oder ...
und einer Prozedur
  p: procedure (...);

Wirklich Sinn ergibt das aber nur, wenn eine Zuweisung eine syntaktische 
eigene Konstruktion ist, und nicht einfach nur ein Rechenausdruck.

In C ist da kein Unterschied. Eine Zuweisung
  a = f(1);
ist einfach nur ein Rechenausdruck, weshalb eben auch
  a = b = f(1); // entspricht a = (b = f(1));
  a = f(b = 1);
möglich ist.

In Sprachen mit getrennten Funktionen und Prozeduren gibt es einerseits 
Zuweisungen:
  <Linkeseite> := <Rechenausdruck>;
und andererseits eben Rechenausdrücke, die nun aber keine Zuweisungen 
enthalten dürfen. In solchen Sprachen sind Prozeduraufrufe eine wiederum 
eigene syntaktische Klasse wie
  p(1);
oder
  call p(1);
und Prozeduraufrufe können in Rechenausdrücken nicht vorkommen. 
Ebensowenig ist in solchen Sprachen
  a + 1;
zulässig, weil ein isolierter Rechenausdruck kein Statement ist.

NB: Da solche Sprachen auch keine impliziten Zuweisungen wie ++/-- 
kennen, tritt in diesen Sprachen das Problem mehrdeutiger 
Interpretationen von
  i = i++ + i++;
überhaupt nicht auf. Dafür fehlt ihnen die für C typische Kurzschrift.

PS: Was ich hier als Syntax anderer Sprachen formuliere, ist grob 
orientiert an Pascal, erhebt aber nicht den Anspruch, wirklich Pascal zu 
sein. Es geht da nur ums Prinzip, nicht um die Details.

c-hater schrieb:
> Der eigentliche Punkt ist aber, dass das Sprachmittel für eine
> offensichtlich bedingungslose Schleife schlicht fehlt und for(;;) nur
> ein sehr nicht-intuitiver Ersatz dafür ist.

Ich hingegen finde es schön, wenn eine Sprache nicht für jeden 
Sonderfall eine eigene Syntax verlangt. Ich finde den C-Weg auch nicht 
unlogisch, wobei mir persönlich "while(true)" besser gefällt.
Die C-Syntax ist eh schon zu komplex, wenn da noch für jeden Spezialfall 
Befehle hinzukommen würden wäre das ja noch schlimmer.

@A.K.:
Ich hoffe du wolltest nicht meine retorischen Fragen beantworten.
Falls ja können wir gerne die Diskusion in Richtung C++ Features der 
letzten 5 Jahre (11/14) vertiefen. ;-)

Carl D. schrieb:
> Ich hoffe du wolltest nicht meine retorischen Fragen beantworten.

Und ich hoffe, ich habe dich mit Antworten auf nicht gestellte Fragen 
nicht überfordert. ;-)

@W.S.
Nachdem du nun eine Woche zu spät sagst wie man es nicht macht, möchtest 
du dann nicht etwas für die Menschheit tun und schreiben wie deiner 
Meinung nach eine Endlosschleife in C auszusehen hat? Falls nein, warum 
deine Antwort?

Hochachtungsvoll,

W.S. schrieb:
> Formulierungen wie obige oder auch while(1) sind entartete Konstrukte,
> weil sie nichts mehr von ihrem eigentlichen Sinn enthalten.

Auch in deinem geliebten Pascal gibt es für Endlosschleifen nur die
"entarteten" Konstrukte

1

 while true do

2

   begin

3

   end;

und

1

 repeat

2

 until false;

Eine nicht entartete Endlosschleife gibt es nur in den wenigsten
Programmiersprachen, bspw. in Scratch:

1

forever

2

  ...

Dem kommt C mit dem for(;;) noch am nächsten, da die Sprachdesigner hier
zwar kein spezielles Schlüsselwort, aber immerhin eine spezielle Syntax
vorgesehen haben.

Yalu X. schrieb:
> Auch in deinem geliebten Pascal gibt es für Endlosschleifen nur die
> "entarteten" Konstrukte
>  while true do
>    begin
>    end;
>
> und
>  repeat
>  until false;

Da ist doch nichts entartet. Das sind Kopf- bzw. fußgesteuerte 
Schleifen, bei denen man EXAKT sieht, wo sie beginnen und enden.

MfG Paul

Leute, die keine "entartete Software" mögen, können sich ja ins stramme 
"Überallnetz" zurückziehen. Oder mit ihren "Zerknalltreibling" in's 
Wirthaus fahren.

Man darf seine Worte auch mit etwas mehr Bedacht wählen, denn manche 
sind einfach verbrannt. Oder eben Grundhaltung.

Carl D. schrieb:
> Man darf seine Worte auch mit etwas mehr Bedacht wählen, denn manche
> sind einfach verbrannt. Oder eben Grundhaltung.

Man kann sich einfach nicht von Irgendjemandem vorschreiben lassen, 
welche Worte man vor lauter Korrektheit nicht mehr verwenden darf. So 
lange der Zusammenhang dadurch klarer und deutlicher wird, sehe ich 
keinen Grund, auf altbekannte Worte zu verzichten, oder gar in das 
allseits beliebte DENGLISCH zu verfallen.

MfG Paul

Paul B. schrieb:
> Man kann sich einfach nicht von Irgendjemandem vorschreiben lassen,
> welche Worte man vor lauter Korrektheit nicht mehr verwenden darf.

Doch. Vom eigenen Gewissen. Hat man keins, ist man natürlich leicht 
raus.

Rufus Τ. F. schrieb:
> Doch. Vom eigenen Gewissen.

Teufel, Mariette! Gewissen?! -Du lieber Himmel! Geht's nicht ein wenig 
undramatischer?

Kopf schüttel

-Paul-

1

for(;;)

ist für mich nur die Abkürzung für:

1

for(i = 0; i < ∞; i++)

Das ist eine reguläre EndlosSCHLEIFE.

W.S. schrieb:
> Also, ein entartetes Konstrukt ist eines, dessen ursprünglicher
> Sinngehalt nicht vorhanden ist.
> Bei einem
> while (bedingung) tu_dies;
>
> ist das eben die Bedingung,

Der ursprüngliche Sinngehalt von while und for ist erstmal die 
wiederholte Ausführung eines Stück Code. Da man diese Wiederholung meist 
an eine Bedingung knüpfen möchte, hat man das gleich mit eigebaut. Die 
unbedingte Ausführung der Schleife kann man nun einfach als Spezialfall 
der bedingten Schleife sehen.

> Wäre da nicht die Notwendigkeit, einer Bedingung im Programmlauf zu
> entsprechen, dann wäre das Wort "while" völlig überflüssig - und zwar in
> jeder Programmiersprache.
>
> Das Gleiche gilt für die "for" Schleife. Der gedachte Zweck ist es, eine
> gleiche Operation auf verschiedene abzählbare Elemente ausüben zu
> können.
>
> Nimmt man dem while seine Bedingung oder dem for seine Abzählung, dann
> entartet man damit dieses Sprachelement.

Nein, man hat einfach nur einen Spezialfall bzw. Trivialfall, sonst 
nichts. Ein

1

printf("Hello world");

ist für mich auch keine entartete Verwendung von printf(), nur weil im 
Formatstring keine Format-Anweisungen stehen und es danach keine 
weiteren Parameter gibt. Die braucht man eben in diesem Fall nicht.

> Es ist für solchen Zweck nicht vorgesehen - obwohl man es syntaktisch so
> benutzen kann (aber beileibe nicht muss).

Wenn man für jeden Spezialfall immer extra noch was vorsehen würde, 
wären die Sprachen noch aufgeblähter, ohne dass daraus irgendein Nutzen 
entstehen würde.

> Das Konstrukt aus marke und goto ist hingegen exakt für unbedingte
> Sprünge und somit für derartige unbedingte Schleifen vorgesehen.

Für mich sind for und while die Konstrukte, die in C für Schleifen 
vorgesehen sind. Goto dagegen eher nicht. Ist für dich sowas wie:

1

if (bedingung)

2

    goto sprungziel;

auch eine entartete Verwendung von goto, da es deiner Aussage nach ja 
nur für unbedingte Sprünge vorgesehen ist und durch das if jetzt aber 
ein bedingter Sprung draus gemacht wird? Bräuchte man ein goto_if 
(bedingung, sprungziel) um diesen Makel der Sprache zu beheben?

D. I. schrieb:
> wie wärs mit:

Geht bei 64-Bit ints in die Hose. UINT_MAX wär besser.

Stimmt, das war Unsinn.

UINT_MAX ist aber trotzdem besser.

Nase schrieb:
> Auf BeOS würde man das einfach so lösen:while (is_computer_on()) {
>
> }

Dazu braucht man kein BeOS
das kannst du dir auch in C so definieren:

#define is_computer_on true
#define die_erde_sich_um_die_sonne_dreht true

-->

while (is_computer_on) { ... }
while (die_erde_sich_um_die_sonne_dreht) { ... }

PS: ... meinte natürlich UINT32_MAX.

◔͜͡◔ ~. schrieb:
> Unsicher: Eine Programmiersprache ist nicht unsicher, sondern ihre
> Laufzeitumgebung.

Die Sprache definiert, was die Laufzeitumgebung kontrollieren kann und 
was nicht. So ist es in C per Sprachdefinition nicht möglich, 
routinemässig bei Array-Zugriffen auf gültige Index-Grenzen zu prüfen. 
Daher ist in diesem Sinn nicht die Laufzeitumgebung unsicher, sondern 
tatsächlich die Sprache.

> Vielleicht gibt es Szenarien in denen es sogar gewollt ist, in
> einem Speicherbereich zu schreiben der nicht der eigene ist?

Eine auf Sicherheit bedachte Sprache wird das als Ausnahmefall sehen und 
dafür spezielle Mechanismen bereitstellen. Der Regelfall sind dann 
abgesicherte Zugriffe. Denn im Regelfall wird so etwas eben nicht 
benötigt.

C ist in hohem Mass nach dem Prinzip "Schrott rein Schrott raus" 
konzipiert. Und es ist vom Anspruch durchdrungen, dass Programmierer 
perfekte Wesen sind, die keine Fehler machen.

Dies darf spätestens seit dem Internet-Zeitalter als gründlich 
gescheitert gelten. Vielmehr müsste es darum gehen, nicht allein vom 
Programmierer eine sichere Programmierung zu verlangen. Sondern man 
sollte ihm Werkzeuge zur Verfügung stellen, die das Ausmass an 
Programmierfehlern so weit reduzieren, wie es jeweils sinnvoll möglich 
ist. C ist kein solches Werkzeug.

c-hater schrieb:
> Der eigentliche Punkt ist aber, dass das Sprachmittel für eine
> offensichtlich bedingungslose Schleife schlicht fehlt und for(;;) nur
> ein sehr nicht-intuitiver Ersatz dafür ist. Eben die typische C-Lösung,
> ursprünglich erzwungen dadurch, daß der Scheiß halt nix anderes als ein
> Makroassembler war.

Kannst Du endlich mal aufhören, jeden C-Thread mit Deinem ideologischen 
Scheiß voll zu müllen? Danke.

vorticon schrieb:
> Also hier die von mir haeufig benutzte Codefloskel:
>
> if(0) {
> ...
> }
>
> Warum? Weil es schneller geht als auszukommentieren!

Ich würde da aber den Präprozessor nutzen:

1

#if 0

Vorteil: Unterscheidet sich optisch besser vom normalen Programm, und in 
dem damit ausgeklammerten Teil können auch Fehler sein, die 
normalerweise nicht durch den Compiler gingen. Das ist vor allem 
praktisch, wenn man von wo anders Code einsetzt und den da drin Schritt 
für Schritt zum laufen bringen will. Es kommt dann nicht gleich ein 
Fehler, nur weil in noch nicht "scharf geschaltetem Code" z.B. eine noch 
fehlende Funktion aufgerufen wird.

A. K. schrieb:
> C ist in hohem Mass nach dem Prinzip "Schrott rein Schrott raus"
> konzipiert.

Schrott bleibt Schrott, auch in anderen Sprachen. Der Gewinn bei dem 
Prinzip "Schrott rein, Edelschrott raus" ist nicht so hoch, wie viele zu 
glauben scheinen. Eine Sprache, die das, was du geschrieben hast, 
automatisch durch das ersetzt, was du eigentlich hättest schreiben 
sollen, gibt es noch nicht.

> Und es ist vom Anspruch durchdrungen, dass Programmierer perfekte Wesen
> sind, die keine Fehler machen.

Es gibt in C einige Fehler, die man in manch anderen Sprachen nicht 
machen kann oder nicht so leicht macht. Und es gibt Fehler, die man auch 
in anderen Sprachen machen kann und die dort leichter vertuscht werden 
können.

A. K. schrieb:
> ◔͜͡◔ ~. schrieb:
>> Unsicher: Eine Programmiersprache ist nicht unsicher, sondern ihre
>> Laufzeitumgebung.
>
> Die Sprache definiert, was die Laufzeitumgebung kontrollieren kann und
> was nicht. So ist es in C per Sprachdefinition nicht möglich,
> routinemässig bei Array-Zugriffen auf gültige Index-Grenzen zu prüfen.

Wo steht denn in der Sprachdefinition, dass die Laufzeitumgebung keine 
Index-Grenzen prüfen darf?

vmni schrieb:
> Und doch existieren entsprechende Funktionen zur Array Verarbeitung die
> auch die Länge überprüfen.

Ich sehe keinen Zusammenhang zwischen dieser Aussage und den Inhalten 
vom Link. Es geht mir um Arrays allgemein und die werden darin nicht 
einmal erwähnt.

So gibt es in C keine Möglichkeit, einer Funktion als Parameter ein 
Array zu übergeben. In der Funktion ist das kein Array mehr, die 
Information über die Länge ist nicht mehr vorhanden. Dass der 
Programmierer diese Länge separat übergeben und Zugriffe zu Fuss prüfen 
kann ist kein gleichwertiger Ersatz dafür.

> Ausserdem musst du in jeder Programmiersprache prüfen ob die
> eingegebenen Daten plausibel sind und überhaupt zur Weiterverarbeitung
> taugen.

Selbstverständlich sollte man vom Programmierer verlangen, dass er 
fehlerfrei programmiert. Solange diese Strategie aber noch nicht 
zufriedenstellend durchsetzbar ist, sollte man immerhin etwas mithelfen, 
indem man ihm Werkzeuge zur Verfügung stellt, die zumindest manche 
Programmierfehler ausbügeln.

Daher ist neben es neben der Forderung an den Programmierer, keine 
Fehler zu machen, trotzdem sinnvoll, zur Laufzeit zu kontrollieren, ob 
er wirklich keinen Fehler gemacht hat. Dort, wo das mit einfachen 
Mitteln möglich ist. Und das setzt eine Sprache voraus, in der das geht.

Rolf M. schrieb:
> Wo steht denn in der Sprachdefinition, dass die Laufzeitumgebung keine
> Index-Grenzen prüfen darf?

Ersetze "darf" durch "kann". C99: In 6.7.5.3.7 beispielsweise: "A 
declaration of a parameter as ‘‘array of type’’ shall be adjusted to 
‘‘qualified pointer to type’"

Es ist nur dort überhaupt möglich, wo die Längeninformation direkt als 
Teil des Arrays vorliegt. Mit Übergabe an eine Funktion geht diese 
Information verloren. Ebensowenig ist es möglich, ein Array dynamisch 
anzulegen und Zugriffe darauf implizit zu kontrollieren.

Allgemein gesagt gibt es keinen Weg, eine Referenz auf ein Array 
irgendwo zu speichern, bei der die Längeninformation irgendwie als Teil 
der Referenz implizit erhalten bleibt. Dort, wo der ursprüngliche Name 
eines Arrays nicht mehr direkt verwendet wird, sind Indexgrenzen nicht 
mehr implizit prüfbar.

Rolf M. schrieb:
> Schrott bleibt Schrott, auch in anderen Sprachen. Der Gewinn bei dem
> Prinzip "Schrott rein, Edelschrott raus" ist nicht so hoch, wie viele zu
> glauben scheinen.

Betrachte Edelschrott == kontrollierter Programmabsturz. ;-)

> Eine Sprache, die das, was du geschrieben hast,
> automatisch durch das ersetzt, was du eigentlich hättest schreiben
> sollen, gibt es noch nicht.

Es geht nicht um den do what I mean, not what I say Compiler, sondern um 
die Frage, was im Falle eines Falles passiert. Eine index out of bounds 
exception, die ein Programm abschmieren lässt, ist bei einem buffer 
overflow die bessere Reaktion, als seelenruhig weiter zu machen.

Man kann selbstverständlich nicht jeden Programmierfehler derart 
ausbügeln. Aber in diesem Fall kann man es in anderen Sprachen bereits 
seit Äonen. In C kann man es nicht.

D. I. schrieb:
> wie wärs mit:
> uint32_t i = 0;
> for(i = 0; i <= (uint32_t) 0xFFFFFFFF; i++);

1

for(uint8_t i = 0; i <= 0xFF; i++)

braucht auf dem µC weniger Speicher ;)

A. K. schrieb:
> C ist in hohem Mass nach dem Prinzip "Schrott rein Schrott raus"
> konzipiert.
"Wenn du eine Funktion mit Scheisse fuetterst, darfst du nicht erwarten, 
dass am Ende Rosen dabei rauskommen."
Ganz Ehrlich: Das finde ich sogar richtig so. Der Programmierer hat sich 
verdammt nochmal gedanken zu machen, was er da macht.

A. K. schrieb:
> Sondern man
> sollte ihm Werkzeuge zur Verfügung stellen, die das Ausmass an
> Programmierfehlern so weit reduzieren, wie es jeweils sinnvoll möglich
> ist. C ist kein solches Werkzeug.
C selbst nicht, aber es gibt genug andere Werkzeuge die vor einer Menge 
moeglicher Fehler und Gefahren warnen. Das faengt schon bei den 
Warnungen des Compilers an. Gerade fuer C/C++ gibt es so viele Werkzeuge 
wie fuer keine andere Sprache. Man muss diese Tools aber auch nutzen 
wollen !
Und da scheitert es nicht an der Sprache oder den Tools, sondern faengt 
bei dem Programmierer selbst an, der so eingebildet ist und meint, dass 
er keine Fehler macht, und geht weiter ueber Fuehrungsebenen die nicht 
genug Zeit einraeumen um Dinge vernuenftig zu Testen.

Um nur mal ein paar dieser Werkzeuge und Methoden zu nennen:
- Valgrind
- CppCheck
- PC-Lint
- Splint
- Unittest
- Fuzzing
- Warnungen des Compilers
- CLang mit seinen Sanitizer-Flags & Co.

Werkzeuge sind mehr als genug vorhanden. Es fehlt aber das Bewustsein 
und die Bereitschaft,
- sich selbst einzugestehen das man Fehler macht
- diese Tools auch nutzen zu wollen !

Neben Fehlern wie einem Speicherueberlauf, sind Logikfehler (glaube ich) 
das viel groessere Problem (wobei man da jetzt streiten kann, ob ein 
Speicherueberlauf aus einem Logikfehler resultiert und damit (indirekt) 
auch ein Logikfehler ist). Und gerade diese beiden Fehler kann man sehr 
gut mit Unittests und Fuzzing finden. Ach nee, dass muesste man ja 
wieder wollen !

Unittests/Fuzzing und Tester/Hacker machen nichts kaputt, sie zeigen, 
dass es schon immer kaputt war.
Solange aber Entwickler angst haben, das jemand aussenstehendes den Code 
besser versteht als sie selbst, und sie angst davor haben, das jemand 
ihr heiliges Kind anfaesst und womoeglich kaputt macht (wie man auch 
immer Code kaputt machen koennen sollte erschliesst sich mir nicht), und 
das finden und aufzeigen von Fehlern als persoenlicher Angriff gewertet 
wird, wird sich nie etwas andern.

Der Mensch (oder besser: seine Eitelkeit und seine Einblidung, dass er 
das non-plus-ultra der Schoepfung ist) ist das Problem, nicht die 
Werkzeuge, die er geschaffen hat.

Ich finde es traurig wie die Schuld immer von einem selbst auf die 
Sprache geschoben wird (das ist bei C so, das ist bei PHP so, und es 
gibt bestimmt noch einen ganzen Sack voll).

Wenn ihr euch mit einem Hammer auf dem Finger haut, dann schreit ja auch 
keiner danach, dass man Haemmer verbieten sollte, weil soooo 
gefaerhlich. Entweder ihr meidet absofort den Gebrauch eines Hammers, 
oder ihr macht euch schlau, wie man es besser macht... oder ihr lasst 
alles beim alten und heult beim naechsten mal wieder.

Die Schuld, dass ihr euch auf dem Finger gehauen habt, liegt aber nicht 
beim Werkzeug, sondern bei euch.
Bei der Programmierung scheint es aber voellig normal zu sein, Fehler 
und Probleme, die aus der falschen Benutzung resultieren, immer auf das 
Tool zu schieben. Ist ja so schoen einfach und angenehm... Man selbst 
macht ja keine Fehler, das Tool ist einfach nur scheisse.

Wenn ihr C ach so scheisse findet, dann nutzt es doch einfach nicht. 
Ach, ihr verdient euer Geld damit? Dann kuendigt doch einfach und sucht 
euch Arbeit, wo ihr C meiden koennt, Gaertner zum Beispiel.
Entwickelt doch eure eigene Sprache, die ganz toll super duper fancy 
ist, und all die Fehler aller anderen Sprachen nicht macht...

Hoert auf zu heulen und macht es besser, oder haltet doch endlich mal 
die Klappe. Ich bin es echt leid...
Meckern und heulen ist ja so schoen einfach, aber aendern will dann doch 
keiner was. Muesste man ja Zeit und Arbeit investieren... Nee, da heult 
man lieber weiter rum und missioniert das Sprache XY ach so scheisse 
ist, weil man sich damit in beide Knie, den linken Fuss und den rechten 
Ellbogen geschossen hat... das man aber bei der Benutzung Fehler gemacht 
hat wird natuerlich verschwiegen, oder aber es wird schoen geredet:
"Also das konnte ja keiner wissen... und deswegen ist die Sprache 
scheisse."

Abgesehen davon, hat das alles schon lange nichts mehr mit dem Thread zu 
tun.

So, und jetzt schmier ick mir ne Stulle, setzt mich auf den Balkon und 
geniesse die Sonne!

A. K. schrieb:
> Rolf M. schrieb:
>> Wo steht denn in der Sprachdefinition, dass die Laufzeitumgebung keine
>> Index-Grenzen prüfen darf?
>
> Ersetze "darf" durch "kann". C99: In 6.7.5.3.7 beispielsweise: "A
> declaration of a parameter as ‘‘array of type’’ shall be adjusted to
> ‘‘qualified pointer to type’"
>
> Es ist nur dort überhaupt möglich, wo die Längeninformation direkt als
> Teil des Arrays vorliegt.

Oder dort, wo man vom Array wieder auf die Länge kommen kann.

> Mit Übergabe an eine Funktion geht diese Information verloren.
> Ebensowenig ist es möglich, ein Array dynamisch anzulegen und Zugriffe
> darauf implizit zu kontrollieren.

Warum? Gerade bei dynamischen Arrays weiß die Laufzeitumgebung die Größe 
sehr wohl. Ohne das könnte man dynamischen Speicher gar nicht sinnvoll 
implementieren.

> Allgemein gesagt gibt es keinen Weg, eine Referenz auf ein Array
> irgendwo zu speichern, bei der die Längeninformation irgendwie als Teil
> der Referenz implizit erhalten bleibt.

Warum sollte das nicht gehen? Sowas wurde durchaus auch gemacht:
https://staff.aist.go.jp/y.oiwa/FailSafeC/index-en.html

> Dort, wo der ursprüngliche Name eines Arrays nicht mehr direkt verwendet
> wird, sind Indexgrenzen nicht mehr implizit prüfbar.

Für dich ist alles unmöglich, für das dir auf die Schnelle keine 
Möglichkeit einfällt, oder?

Rolf M. schrieb:
> Ich würde da aber den Präprozessor nutzen:
> #if 0

Ich auch :)

> Vorteil: Unterscheidet sich optisch besser vom normalen Programm,

In einigen Editoren und IDEs wird der damit umschlossene Codeabschnitt
sogar als Kommentar gehighlightet.

> und in dem damit ausgeklammerten Teil können auch Fehler sein, die
> normalerweise nicht durch den Compiler gingen.

Man kann damit auch komplette Funktionen, globale Deklarationen,
Makrodefinitionen u.v.m. auskommentieren, was mit if(0) alles nicht
möglich ist.

Rolf M. schrieb:
> A. K. schrieb:
>> C ist in hohem Mass nach dem Prinzip "Schrott rein Schrott raus"
>> konzipiert.
>
> Schrott bleibt Schrott, auch in anderen Sprachen. Der Gewinn bei dem
> Prinzip "Schrott rein, Edelschrott raus" ist nicht so hoch, wie viele zu
> glauben scheinen.

Das Ziel bei den "besseren" Sprachen ist es weniger, auf Schrott etwas
Gutes zu machen, sondern

1. die Folgen der schrottigen Programmierung in überschaubaren Grenzen
   zu halten oder

2. potentiellen Schrott gar nicht erst zu ermöglichen.

Punkt (1) geschieht typischerweise durch Lauffzeitprüfungen, die das
Programm im Fehlerfall einfach abbrechen, bevor Schlimmeres passiert.
Nur ist ein Programmabbruch nicht in allen Anwendungsfällen eine
akzeptable Lösung, da "nichts tun" manchmal genauso fatal wie "das
Falsche tun" ist.

Punkt (2) geschieht durch restriktivere Sprachkonzepte wie bspw.
- Verzicht auf Zeigerarithmetik
- strengere Typprüfung
- andere Programmierparadigmen wie bspw. die funktionale Programmierung,
  wo sich logische Programmfehler (sofern sie überhaupt syntaktisch
  möglich sind) oft in einer anderen, leichter zu prüfenden Fehlerart
  (bspw. Typfehlern) niederschlagen.

Wo diese Punkte nicht anwendbar sind, weil die die einzusetzende
Programmiersprache fest vorgegeben ist, kann versucht werden, mittels
zusätzlicher Tools zur statischen Codeanalyse potentiellen Schrott als
solchen zu erkennen und abzuweisen.

Alle genannten Möglichkeiten reduzieren zwar die Wahrscheinlichkeit von
Fehlern oder deren Folgen, Softwareentwicklung ganz ohne Mitdenken des
Programmierers wird es aber vermutlich nie geben :)


Rolf M. schrieb:
> https://staff.aist.go.jp/y.oiwa/FailSafeC/index-en.html

Interessantes Projekt, werde ich mir mal etwas genauer anschauen.

◔͜͡◔ ~. schrieb:
> Tasg schrieb:
>> Bei C macht es doch keinen Sinn, die Syntax der Sprache zu hinterfragen.
>> Die ganze Sprache ist unübersichtlich, unlogisch, unsicher und veraltet
>> - aber dagegen sehr effizient.
>
> Unübersichtlich: Wenn man die Syntax nicht versteht, ist jede Sprache
> unübersichtlich. Und ich empfinde C als einfach.

Funktionszeiger.

A. K. schrieb:
>> Vielleicht gibt es Szenarien in denen es sogar gewollt ist, in
>> einem Speicherbereich zu schreiben der nicht der eigene ist?
>
> Eine auf Sicherheit bedachte Sprache wird das als Ausnahmefall sehen und
> dafür spezielle Mechanismen bereitstellen. Der Regelfall sind dann
> abgesicherte Zugriffe. Denn im Regelfall wird so etwas eben nicht
> benötigt.

Stichwort "unsafe block" in C# oder Rust.

◔͜͡◔ ~. schrieb:
> Veraltet: Alt ist nicht veraltet. Ein etwas hinkendes Beispiel:
> Windows ist auch alt, ist Windows deshalb veraltet? Nein.
> C als auch Windows werden kontinuierlich weiterentwickelt bzw.
> standardisiert.

Inwiefern wurde C seit Ansi-C (1989) weiterentwickelt? Man hat ein paar 
nette und nützliche Dinge hinzugefügt, aber das wars schon. Kein 
Vergleich zu anderen Sprachen oder gar zu Windows.

A. K. schrieb:
> Dies darf spätestens seit dem Internet-Zeitalter als gründlich
> gescheitert gelten. Vielmehr müsste es darum gehen, nicht allein vom
> Programmierer eine sichere Programmierung zu verlangen. Sondern man
> sollte ihm Werkzeuge zur Verfügung stellen, die das Ausmass an
> Programmierfehlern so weit reduzieren, wie es jeweils sinnvoll möglich
> ist. C ist kein solches Werkzeug.

Ich verstehe bis heute nicht wie man sicherheitskritische Software wie 
OpenSSL heutzutage in C schreiben kann. Mit C fliegt man früher oder 
später gehörig auf die Schnauze, egal wie sorgfältig man versucht zu 
sein.

Kaj G. schrieb:
> Ich finde es traurig wie die Schuld immer von einem selbst auf die
> Sprache geschoben wird (das ist bei C so, das ist bei PHP so, und es
> gibt bestimmt noch einen ganzen Sack voll).

? So einfach ist es nicht. Programmiersprachen sind nicht für 
gottgleiche Wesen geschaffen worden sondern für Menschen. Eine Maschine 
die durch einen sehr einfachen Bedienfehler großen Schaden anrichtet, 
hat das Ziel verfehlt, menschgerecht bedienbar zu sein. Man kann einem 
Menschen schwer vorwerfen, ein Mensch zu sein.

Kaj G. schrieb:
> Um nur mal ein paar dieser Werkzeuge und Methoden zu nennen:
> - Valgrind
> - CppCheck
> - PC-Lint
> - Splint
> - Unittest
> - Fuzzing
> - Warnungen des Compilers
> - CLang mit seinen Sanitizer-Flags & Co.

MISRA-C hast du noch vergessen. Es ist unglaublich, welch ein Aufwand 
betrieben wird um C sicher zu machen. Lieber kämpft man 40 Jahre weiter 
mit so einer Sprache, anstatt das man mal ein Werkzeug nutzt, dass die 
gewünschte Sicherheit von selbst garantiert und Mechanismen bietet diese 
explizit auszuschalten. Ist das schon Dekadenz?

@W.S.:

Ich bin verwundert, dass ausgerechnet ein Pascal-Fan wie du hier die
Verwendung von Goto so vehement propagiert, dazu noch in einem
Anwendungsfall, bei dem man problemlos auch mit strukturierten
Sprachelementen zu Ziel kommt.

Was soll denn der Herr Wirth von dir denken, wenn er deine Ausführungen
hier liest? ;-)

Mit der Einführung der strukturierten Programmierung wurde Goto zunächst
komplett verteufelt. Irgendwann hat man eingesehen, dass bei manchen
Dingen – wie bspw. bei der Fehlerbehandlung mit vielen Prüfbedingungen –
der Einsatz von Goto die Verschachtelungstiefe von If-Anweisungen
reduzieren und somit zur Übersichtlichkeit beitragen kann. Dazu werden
aber nur Vorwärtssprünge benötigt. Rückwärtssprünge mit Goto gelten
nach wie vor als böse¹.

Und jetzt kommst du, und empfiehlst, Goto gerade auch (oder sogar
ausschließlich?) für Rückwärtssprünge zu verwenden. Dir ist schon klar,
dass du mit dieser Idee allein auf weiter Flur stehst?

Nur so aus Interesse:

Wie würdest du eine Schleife schreiben, die ihre Abbruchbedingung in der
Mitte hat? Also bspw. so etwas:

1

  for(;;) {

2

    // mehrere Zeilen Code

3

4

    if(bedingung)

5

      break;

6

7

    // mehrere Zeilen Code

8

  }

Wann man das, was du bisher geschrieben hast, konsequent weiterführt,
müsste diese Schleife bei dir so aussehen (da es in selbstgebastelten
Goto-Schleifen ja kein Break gibt):

1

  loop1:

2

    // mehrere Zeilen Code

3

4

    if(bedingung)

5

      goto end1;

6

7

    // mehrere Zeilen Code

8

  goto loop1;

9

10

  end1:

11

  ...

Damit haben wir zwei überkreuzende Goto-Sprünge, also genau das, was
gemeinhin als Spaghetticode bezeichnet wird. Spätestens, wenn zwei
Schleifen dieses Typs ineinandergeschachtelt werden, ist das Chaos
perfekt :)

—————————————
¹) Übrigens hat auch MISRA genau diese Entwicklung durchgemacht: Früher
   waren Gotos generell verboten, heute gilt das strikte Verbot nur noch
   für Rückwärtssprünge.

Ich habe nicht den Eindruck, daß es den Diskutanten in diesem Thread 
bislang sonderlich auf sachliche Argumente angekommen wäre. Das ist bei 
Programmiersprachenflamewars auch unnötig, denn da hat ja prinzipbedingt 
jeder recht. Und zwar ausschließlich.

@Rufus: Da kam schon Information rüber. Dieser Ansatz war mir unbekannt:

Yalu X. schrieb:
> Rolf M. schrieb:
>> https://staff.aist.go.jp/y.oiwa/FailSafeC/index-en.html
>
> Interessantes Projekt, werde ich mir mal etwas genauer anschauen.

Christopher C. schrieb:
> Ich verstehe bis heute nicht wie man sicherheitskritische Software wie
> OpenSSL heutzutage in C schreiben kann.

Na in welcher Sprache denn sonst? C-Code kann man praktisch in allem 
anderen relativ einfach einbinden, egal ob Java, .net, Python, u.s.w. in 
allen Versionen. Welche andere Sprache bietet das so?
Ich glaube auch nicht, dass man eine bessere Fehlerfreiheit bekommt, 
wenn man für ein Dutzend Sprachen ein Dutzend separate 
SSL-Implementationen schreibt, die dann alle separat gepflegt werden 
müssen.

W.S. schrieb:
> Nochmal zum Mitschreiben: Es sind Schlüsselwörter, die zum bedingten
> Ausführen von irgendwas in der Sprache benötigt werden. So herum.

Nö. Wenn jemand mir sagt, dass er for nutzen möchte, ist das erste, was 
mir in den Sinn kommt nicht: "Der will etwas bedingt ausführen", sondern 
"der will etwas in einer Schleife ausführen".

> Versuche doch mal, dir ein if vorzustellen ohne eine Bedingung ("Da
> man diese Wiederholung MEIST an eine Bedingung knüpfen möchte..").

Im Gegensatz zu dir habe ich nicht von if gesprochen, sondern nur von 
for und while. Das sind Schleifenkonstrukte.

W.S. schrieb:
> ◔͜͡◔ ~. schrieb:
>> Und ich empfinde C als einfach.
>
> Was du empfindest, ist deine Gewöhnungssache. Tatsächlich ist C
> unübersichtlich.

So kann man sich die Welt auch einfach machen: Die Meinung anderer als 
persönliches Gefühl und die eigene einfach als Tatsache hinstellen.

> Warum? Weil in C extrem an menschlich lesbaren
> Schlüsselwörtern gespart wurde und stattdessen mit sonstigen Satzzeichen
> in unterschiedlichster Kombination gearbeitet wird.
> Beispiel gefällig?   *  *A */ X*A X**A A*
> Andere Programmiersprachen sind da wesentlich übersichtlicher, da von
> hause aus besser lesbar.

Und doch hat ein Großteil der modernen Sprachen viele dieser 
Syntaxelemente übernommen.

> Sowas wie begin und end versteht selbst ein totaler Laie auf Anhieb.

Programmieren besteht nicht nur aus dem Verstehen von ein paar 
Schlüsselwörtern. Der wesentlich schwierigere Teil ist bei allen 
Sprachen erforderlich. Daher sehe ich es nicht als besonderen Vorteil 
an, wenn ein totaler Laie ein paar mehr Syntaxelemente versteht.

>> Unlogisch: Inwiefern ist die Sprache unlogisch? Logik wird doch durch
>> den Programmierer entwickelt.
>
> Nö. Manche Sprachen sind tatsächlich logisch aufgebaut (wie Pascal oder
> Algol) und C ist eben nicht logisch aufgebaut, sondern diktatorisch.
> So nach dem Motto "hier wird das eben so gemacht, basta!"

Was ist das denn für ein Quatsch? Das gilt doch für alle Sprachen. Sie 
haben Regeln, an die man sich zu halten hat. Diktatorisch ist das immer.

> Beispiel:
> warum wurde das Gleichheitszeichen als Zuordnungsoperator mißbraucht, wo
> doch seit Erfindung der Mathematik selbiges als Gleichheitszeichen
> bereits vergeben ist und an allen Ecken bei C zusammengesetzte Zeichen
> üblch sind?

Da hast du wohl "unlogisch" mit "unintuitiv" verwechselt. Letzteres ist 
C an eigigen Stellen durchaus.

> Fehlentscheidung! Und die zieht weiteren Mumpitz nach sich,
> wie z.B. A==B

Wer hat denn festgelegt, dass man in der Programmierung Symbole 
ausschließlich im mathematischen Sinne nutzen darf?
Hast du mal eine Sprache parat, bei der das Gleichheitszeichen nicht 
"mißbraucht" wird? In Pascal z.B. wird es für den Vergleich eingesetzt, 
was genauso wenig dem mathematischen Sinn entspricht wie eine Zuweisung.

> Oder warum  muß der Ausdruck nach if denn in eine Klammer? Es gibt doch
> gar nichts zu klammern!
> bei einem Term  (A+B)*C ist klar, daß hier Klammern sein müssen, sonst
> ginge die Rechnung falsch. Aber wozu bei einem if ? Bloß, um sowas wie
> ein then zu vermeiden?

Was ist daran unlogisch? Umgekehrt könnte man auch fragen, warum man in 
Pascal extra ein Schlüsselwort then braucht. Bloß, um sowas wie Klammern 
zu vermeiden? Wie kommst du auf die Idee, ein then in einer if-Anweisung 
sei der gottgegebene Weg, von dem niemals je abgewichen werden darf?

> Oder wozu bei
> if (CharAvailable()) c = GetChar();
> die leeren Klammern, wo doch von vornherein feststeht, daß die
> betreffenden Funktionen gar keine Argumente benötigen?

Die Klammern mit den Argumenten dazwischen nach dem Identifier zeigen 
unmissverständlich, dass die Funktion aufgerufen werden soll. Wenn man 
keine Argumente zu übergeben hat, steht zwischen den Klammern eben 
nichts. Finde ich völlig logisch und auf jeden Fall besser, als wenn da 
einfach nur ein Name stünde, ohne irgendetwas, das zeigt, was denn mit 
damit überhaupt zu tun ist.

> Die Sprache macht es den Programmierern schwer, da sie keinerlei
> Sauberkeit kennt. Da wird lustig zwischen Typdefinitionen,
> Variablendeklarationen und Code gewuselt, ohne selbige sauber zu
> trennen, selbst Konstantendefinitionen lassen sich nur per Präprozessor
> - also außerhalb der eigentlichen Programmiersprache erledigen.

Ja, das fehlt tatsächlich.

> Den Treppenwitz mit sowas wie "uint32_t" und Konsorten, die erstens
> unleserlich sind und zweitens überhaupt nicht im Compiler verankert
> sind, sondern per Headerdatei auf das alte schlichte unsigned long int
> zurückgeführt werden, bevor der eigentliche Compiler sie zu fressen
> kriegt, kenne wir ja zur Genüge.

Was ist an uint32_t unleserlich? Und warum muss das unbedingt ein 
eigenes Schlüsselwort bekommen? Welchen Vorteil hätte das, außer dass 
älterer Code, der selbst einen solchen Namen definiert, inkompatibel 
dazu wird? So kann man dieses zusätzliche Feature über einen Header 
einbinden, wenn man es braucht und weglassen, wenn nicht. Welchen 
Nachteil hat es denn?

Rolf M. schrieb:
> Christopher C. schrieb:
>> Ich verstehe bis heute nicht wie man sicherheitskritische Software wie
>> OpenSSL heutzutage in C schreiben kann.
>
> Na in welcher Sprache denn sonst? C-Code kann man praktisch in allem
> anderen relativ einfach einbinden, egal ob Java, .net, Python, u.s.w. in
> allen Versionen. Welche andere Sprache bietet das so?
> Ich glaube auch nicht, dass man eine bessere Fehlerfreiheit bekommt,
> wenn man für ein Dutzend Sprachen ein Dutzend separate
> SSL-Implementationen schreibt, die dann alle separat gepflegt werden
> müssen.

C++, Go und Rust können C-ABI kompatible Funktionen erstellen, die 
lassen sich dann von allerhand anderen Sprachen benutzen. Das ist 
heutzutage kein Argument mehr. Gut damals, gabs nur C++, aber das wäre 
schon ein riesiger Fortschritt zu C (Typsicherheit, Arrays mit Bounding 
checks...).

W.S. schrieb:
> Wer if und else hinschreiben kann, braucht keinen Fragezeichenoperator.

Der Fragezeichenoperator ist schon sinnvoll, weil er einiges an 
redundanter Schreiberei einsparen helfen kann.


Willkürliches dahingetippseltes Beispiel:

1

pstruct->myvaluearray[index] = index % 2 ? function_1(index) : function_2(index);

Ohne Fragezeichenoperator sähe das so aus:

1

if (index % 2)

2

  pstruct->myvaluearray[index] = function_1(index);

3

else

4

  pstruct->myvaluearray[index] = function_2(index);

Da steht also zweimal das gleiche.

Man muss sich vor Augen führen: C ist keine Programmiersprache, die 
dafür da ist, das Programmieren zu erlernen. C ist eine 
Programmiersprache, die dafür da ist, Ziele zu erreichen. Und mit ihren 
Freiheiten auch viel Verantwortung seitens des Nutzers mit sich bringt.

W.S. schrieb:
> Und nochwas, nicht an dich selbst:
> Mir ist es eigentlich auch zu doof, auf Einwürfe wie "Was ist an
> uint32_t unleserlich?" näher einzugehen.

Hätte ich auch nicht anders erwartet. Wie oben schon geschrieben, 
erklärst du einfach deine Meinung zur unumstößlichen Tatsache, in dem 
Irrglaube, dass damit eine Begründung überflüssig wird.

> Abgesehen davon ist uint32_t herzlich überflüssig, ein dword oder
> unsigned long int hätte es auch getan.

Du hast offenbar nicht verstanden, wozu die fixed-width-Integers 
überhaupt eingeführt wurden. unsigned long int ist auf manchen 
Plattformen 64 Bit breit, und "dword" ist eine prozessorspezifische 
Bezeichnung.
Und wie "dword" oder "unsigned long int" leserlicher für einen 
32-Bit-Typ sein soll als eine Bezeichnung in der die Zahl 32 auch 
tatsächlich enthalten ist, wird wohl dein Geheimnis bleiben.

W.S. schrieb:
> Noch ein Nachtrag:
>
> siehe
> "Beitrag "Aus einer while Schleife springen"
>
> Da kann man mal sehr schön sehen, wie sich Leute in sich selbst
> verstricken, wenn sie mit sowas wie while(1) herumhantieren, ohne
> wirklich irgend einen Durchblick zu haben.

Wie überraschend, dass jemand, der keinen Durchblick hat, sein Problem 
nicht versteht. Und was hat das mit while (1) zu tun? Inwiefern wäre das 
mit deinem goto-Konstrukt anders gewesen?

◔͜͡◔ ~. schrieb:
>> Christopher C. schrieb:
>> Inwiefern wurde C seit Ansi-C (1989) weiterentwickelt? Man hat ein paar
>> nette und nützliche Dinge hinzugefügt, aber das wars schon. Kein
>> Vergleich zu anderen Sprachen oder gar zu Windows.
> C11 ersetzt C99.
> Inwiefern die Änderungen einen Fortschritt darstellen... Man mag die
> Frage mal rumdrehen: Braucht es einen Fortschritt? Oder gibt es derzeit
> keinen Verbesserungsbedarf für C? Ich glaube eher nicht.

"Braucht es Fortschritt?". Nun, du kannst gerne wieder ein Leben in 
einer Höhle führen, ohne fließendes Wasser und ein warmes Bett. Nein mal 
im Ernst, was soll so eine Frage in der Informationstechnik? C ist 
inzwischen 40 Jahre alt, da gibt es so einiges was man heutzutage anders 
macht. Mir ist keine Sprache bekannt die in den letzten 20 Jahren 
erfunden wurde und keine Typsicherheit bietet. Genauso sieht es aus mit 
Templates/Generics aus. etc. etc.

Aha und was macht C11 grundsätzlich anders als C99 oder C89? Das Gremium 
macht bewusst keine großen Änderungen. Nun zu behaupten C11 sei eine 
"Weiterentwicklung" von C99 ist eher ein Witz.

◔͜͡◔ ~. schrieb:
>> Christopher C. schrieb:
>> Stichwort "unsafe block" in C# oder Rust.
> Wir reden hier von C und du konterst plötzlich mit C# und irgendeiner
> anderen Programmiersprache?
> Wenn du das anders meintest, wärs auch schön wenn du ein paar Worte dazu
> verlierst statt einfach nur 2 Namen in den Raum zu werfen.

Also bitte, was soll eigentlich dieser Tonfall? Du musst meine Aussage 
schon im richtigen Kontext interpretieren und das darüber liegende Zitat 
miteinbeziehen.

Schau mal hier:
Christopher C. schrieb:
> A. K. schrieb:
>>> Vielleicht gibt es Szenarien in denen es sogar gewollt ist, in
>>> einem Speicherbereich zu schreiben der nicht der eigene ist?
>>
>> Eine auf Sicherheit bedachte Sprache wird das als Ausnahmefall sehen und
>> dafür spezielle Mechanismen bereitstellen. Der Regelfall sind dann
>> abgesicherte Zugriffe. Denn im Regelfall wird so etwas eben nicht
>> benötigt.
>
> Stichwort "unsafe block" in C# oder Rust.

Darüberhinaus ist es so schwer "rust unsafe block" zu googeln, wenn man 
sowieso vorm PC sitzt?

https://doc.rust-lang.org/book/unsafe.html

Um es zusammenzufassen, geht es um einen Scope, in dem man all die 
Schweinerein, wie in einen fremden Addressraum zu schreiben etc., 
erlaubt sind. Ansonsten ist sowas untersagt und endet mit einer 
Fehlermeldung des Kompilers.

W.S. schrieb:
> Was du empfindest, ist deine Gewöhnungssache. Tatsächlich ist C
> unübersichtlich. Warum? Weil in C extrem an menschlich lesbaren
> Schlüsselwörtern gespart wurde und stattdessen mit sonstigen Satzzeichen
> in unterschiedlichster Kombination gearbeitet wird.
> Beispiel gefällig?   *  *A */ X*A X**A A*
> Andere Programmiersprachen sind da wesentlich übersichtlicher, da von
> hause aus besser lesbar. Sowas wie begin und end versteht selbst ein
> totaler Laie auf Anhieb.

Genau deshalb finde ich C gegenüber Pascal wesentlich übersichtlicher. 
Weil nicht soviel Buchstabenballast das Wesentliche überdeckt. 
Buchstaben sind in C bis auf wenige Ausnahmen (if, while, for..)für 
Typen und Namen vorgesehen, strukturiert wird mit anderen Zeichen. Diese 
deutlich sichtbare Trennung zwischen Struktur und Inhalt erleichtert mir 
das Lesen wesentlich.


Ein Quelltext ist nicht für totale Laien gedacht, sondern für 
Programmierer und Compiler. Dass ein '{' für den Beginn eines Blocks 
steht und '}' für das Ende, ist ja nun wirklich nicht schwer zu lernen.

Wenn es dir mit vielen 'begin' und 'end' lieber ist, brauchst du nur

#define begin {
#define end }

an den Anfang setzen und der C-Compiler versteht auch deine 
Lieblingsschreibweise. C ist eben nicht diktatorisch, sondern erlaubt 
mehr Freiheiten als jede andere Sprache.

> Oder warum  muß der Ausdruck nach if denn in eine Klammer? Es gibt doch
> gar nichts zu klammern!
> bei einem Term  (A+B)*C ist klar, daß hier Klammern sein müssen, sonst
> ginge die Rechnung falsch. Aber wozu bei einem if ? Bloß, um sowas wie
> ein then zu vermeiden?

'()' sind 2 Anschläge weniger als 'then' und besser als Strukturierung 
erkennbar.

Aber auch für dieses Problem von dir gibt es eine Lösung:

#define IF if(
#define THEN )

W.S. schrieb:
> Viel wichtiger ist Lesbarkeit - insbesondere dann, wenn man nach jahren
> an seinen eigenen Code nochmal ran muß oder wenn man Zeugs von anderen
> übernehmen oder korrekturlesen muß.

C-Code ist lesbar. Wenn man damit arbeitet.

Ich habe keine Probleme damit, 20 Jahre alten Code von mir zu lesen oder 
zu überarbeiten. Damit verdiene ich mir mein Brot.

Nochmal: C ist keine Sprache, die dafür gedacht ist, 
Programmieranfängern das Programmieren nahezubringen, oder Leuten beim 
Vermeiden von Fehlern zu helfen. Wer so etwas braucht, soll etwas 
anderes nehmen. Vielleicht ist auch nicht jeder gleichermaßen dafür 
geeignet, als Programmierer/Softwareentwickler o.ä. zu arbeiten?

C ist ein anspruchsvolles Werkzeug, das Übung und Erfahrung erfordert, 
um es beherrschen zu können.

W.S. schrieb:
> Tipparbeit einsparen zu wollen, halte ich für das Verkehrteste auf
> dieser Welt.

Im von mir gebrachten Beispiel wird fehlerträchtige Redundanz 
eingespart.

Soll nämlich der Code irgendwann überarbeitet werden, müsste dringend 
darauf geachtet werden, die beiden Zuweisungszeilen gleichermaßen zu 
bearbeiten. Geschieht das nicht, kann das ... interessante Effekte 
haben.

W.S. schrieb:
> Rufus Τ. F. schrieb:
>> Der Fragezeichenoperator ist schon sinnvoll, weil er einiges an
>> redundanter Schreiberei einsparen helfen kann.
>
> Ist dir DAS etwa wichtiger als der Rest der Welt?
>
> Mir nicht.
>
> Viel wichtiger ist Lesbarkeit

Redundanter Code ist (fast) immer schlecht, gerade auch im Hinblick 
auf
die Lesbarkeit. Nehmen wir das obige Beispiel von Rufus:

1

if (index % 2)

2

  pstruct->myvaluearray[index] = function_1(index);

3

else

4

  pstruct->myvaluearray[index] = function_2(index);

Ich brauche mindestens 3 Sekunden, um zuverlässig zu erkennen, dass in
beiden Zweigen etwas demselben Objekt (in diesem Fall einem bestimmten
Array-Element innerhalb einer Struktur) zugwiesen wird. Der Ausdruck auf
der linken Seite des Zuweisungsoperators könnte aber auch komplizierter
sein, dann dauert es entsprechend länger.

Mit dem ?:-Operator besteht dieses Problem überhaupt nicht:

1

pstruct->myvaluearray[index] = index % 2

2

                               ? function_1(index)

3

                               : function_2(index);

Hier sehe ich auf einen Blick, dass dem Objekt auf der linken Seite auf
jeden Fall etwas zugewiesen wird. Als nächstes sehe ich, dass der
zugewiesene Wert davon abhängt, ob index ungerade oder gerade ist.
Schließlich sehe ich die beiden zur Auswahl stehenden Ausdrücke.

Genau in dieser Reihenfolge und ohne die Verdoppelung einzelner
Codeabschnitte möchte ich das lesen, da mein Gehirn beim Verstehen des
Codes ebenfalls in dieser Reihenfolge arbeitet.

Es kann natürlich sein, dass andere Gehirne anders arbeiten. Aber ich
glaube, so arg groß sind die Unterschiede nicht.

W.S. schrieb:
> Und was dein Einwand wegen einer Abbruchbedingung inmitten einer
> Schleife betrifft: Jede Schleife würde sich so umstellen lassen, daß man
> genau dieses nicht braucht - es sei denn, man hat ein Problem, das
> dediziert nach einem goto verlangt. Ist aber eher selten.

Genau da haben wir das Problem mit dem redundanten Code sogar noch in
verschärfter Form. Natürlich kann man diese Schleife

1

  for(;;) {

2

    // Codeabschnitt A

3

4

    if(bedingung)

5

      break;

6

7

    // Codeabschnitt B

8

  }

so umstellen, dass die Abbruchbedingung am Anfang der Schleife steht:

1

  // Codeabschnitt A

2

3

  while(!bedingung) {

4

    // Code-Abschnitt B

5

6

    // Codeabschnitt A

7

  }

Jetzt steht aber der Codeabschnitt A zweimal da. Jemand, der das
Programm liest, wird – wenn überhaupt – erst nach längerem Hinsehen
erkennen, dass da ein Stück Code vor der Schleife mit einem Teil des
Codes in der Schleife übereinstimmt. Da er ja nicht einmal im Voraus
weiß, ob es überhaupt gleichen Code gibt und welche Code-Zeilen er dazu
vergleichen muss, bedarf es extrem guter Mustererkennungsfähigkeiten des
Gehirns, die leider nicht jeder hat.

Hat er schließlich nach langem Hinstarren erkannt, dass es sich dabei
tatsächlich um eine umgestellte Schleife handelt, wird er jubeln, sich
aber gleichzeitig fragen, warum der Idiot von Programmierer das nicht
gleich so hingeschrieben hat.

Aber das ist noch nicht alles:

Jede Änderung, die innerhalb der Schleife in Codeabschnitt A gemacht
wird, muss auch in den Zeilen vor der Schleife gemacht werden. Ich habe
es schon oft erlebt, dass danach die Änderung vor der Schleife
fehlerhaft ist. Denn bei der Änderung innerhalb der Schleife ist man
noch gezwungen nachzudenken, beim Kopieren der entsprechenden Änderung
vor die Schleife wird man leichtsinnig. Oft fehlt dann einfach eine
Zeile, oder eine Zeile steht plötzlich doppelt da.

So ein ähnliches Problem wurde von Dan Saks auf der CppCon 2016 
behandelt:
“extern c: Talking to C Programmers about C++” 
https://youtu.be/D7Sd8A6_fYU
Geht zwar 1,5h, aber die lohnen sich.

Sein Fazit (in meiner Zusammenfassung):
Verbohrte kann man mit Argumenten nicht überzeugen.

Da ich mir nicht vorwerfen lassen will, ich würde den Thread kapern:
Beitrag "Re: Gibt es eine Programmiersprache mit diesem Schleifentyp?"

mc.net at its best schrieb:
> Frage: for(;;) bedeutung
> Antwort: Endlosschleife
> mc.net: 110 Antworten

Das liegt u.a. daran, dass deine Antwort "Endlosschleife", so knackig
kurz und prägnant sie auch sein mag, nur einen winzigen Bruchteil der
gesamten Wahrheit ans Licht bringt:

Eine Schleife mit for(;;) muss mitnichten endlos laufen, denn sie darf
selbstverständlich mit einer Break-, Goto- oder Return-Anweisung schon
deutlich vor dem Ende der Ewigkeit verlassen werden ;-)

Zeno:
> . Das Schlimme dabei der Compiler meckert nicht und läßt das durchgehen.
> Klar der Code funktioniert dann nicht wie gewünscht und man sucht sich
> einen Wolf.

Dann besorg dir einen Compiler, der was taugt. Der von mir benutzte ist 
kostenlos zu bekommen und hat kein Problem damit Anfängerfehler zu 
finden.

Hallo,
> Übrigens am besten finde ich den Zuweisungsoperator von HP-Basic. Dort
> sieht das so aus :
>
>     a->2
>

Für mich ist das unlogisch b.z.w. unintuitiv. Ich lese da "weise den 
Wert der Variabel a der Konstante 2 zu", gemeint ist aber sicherlich das 
Gegenteil.

rhf

Zeno schrieb:
> Carl D. schrieb:
>> Dann besorg dir einen Compiler, der was taugt. Der von mir benutzte ist
>> kostenlos zu bekommen und hat kein Problem damit Anfängerfehler zu
>> finden.
>
> OK! Dann schmeiß ich den GCC weg.
>
> Zeno

Oder les einfach mal was er ausgibt.

Zeno schrieb:
> Rolf M. schrieb:
>> Und doch hat ein Großteil der modernen Sprachen viele dieser
>> Syntaxelemente übernommen.
>
> Da diese i.d.R alle C-lastig sind.

Java ist "C-lastig"? Was hat Java denn mit C zu tun, außer eben, dass es 
die ganzen Sonderzeichen in ihrer Bedeutung übernommen hat?

Zeno schrieb:
> Ein Gleichheitszeichen bedeutet im mathematischen Sinn, das auf beiden
> Seiten von selbigen das Gleiche steht. Insofern macht Pascal es richtig,
> denn es prüft beim Vergleich ob auf beiden Seiten das Gleiche steht.

Ebent, und das sind zwei ganz unterschiedliche Dinge. In der Mathematik 
heißt x=3, dass x hiermit den Wert 3 hat. Es wird nichts geprüft oder 
so, sondern einfach festgelegt. Wenn ich in Pascal x=3 schreibe, bekommt 
x dadurch überhaupt nicht den Wert 3, sondern kann auch einen ganz 
anderen Wert haben.

Zeno schrieb:
> Rufus Τ. F. schrieb:
>> Ohne Fragezeichenoperator sähe das so aus:
>> if (index % 2)
>>   pstruct->myvaluearray[index] = function_1(index);
>> else
>>   pstruct->myvaluearray[index] = function_2(index);
>>
>> Da steht also zweimal das gleiche.
>
> Nö da steht nicht 2x das Gleiche! Das was rechts vom Gleichheitszeichen
> steht ist schon unterschiedlich.

Richtig, das bleibt bei der ?:-Variante ja auch separat. Aber links 
steht zweimal exakt das gleiche, und genau diese Duplizierung 
verschwindet durch die Verwendung von ?:.

Zeno schrieb:
> Yalu X. schrieb:
>> Hier sehe ich auf einen Blick
>
> Du bist da Hellseher. Ich sehe da nichts auf einen Blick. DA muß ich
> schon mal das Handbuch zur Hand und nachschauen was das ? da bedeuten
> soll, um dann festzustellen daß es nichts anderes als if .. else ist.

Nein, er ist nicht Hellseher, sondern hat einfach nur die Sprache 
gelernt, die er benutzt. Der ?:-Operator ist ja nun nicht gerade 
Raketenwissenschaft. Und zu den Grndlagen beim Lernen einer Sprache 
gehört, dass man einen Überblick darüber bekommt, welche Operatoren es 
gibt und was sie machen.

> Sorry aber da ist mir die klassische Schreibweise schon lieber.

Was nun die "klassische Schreibweise" ist, darüber kann man auch 
streiten. Früher war z.B. in Shellskripten auch die Schreibweise

1

Bedingung && AktionWennWahr || AktionWennFalsch

nicht unüblich. Und die funktioniert sogar auch in C, wenn die Aktionen 
einen passenden Typ zurückgeben.

Zeno schrieb:
> Carl D. schrieb:
>> Dann besorg dir einen Compiler, der was taugt. Der von mir benutzte ist
>> kostenlos zu bekommen und hat kein Problem damit Anfängerfehler zu
>> finden.
>
> OK! Dann schmeiß ich den GCC weg.

Gerade der GCC warnt da schon immer. Man muss aber natürlich die 
Warnungen auch einschalten und lesen.

Zeno schrieb:
> In meinem Post ging es darum, daß der Compiler einen klaren
> syntaktischen Fehler durchgehen läßt. In der if - Bedingung wird ein
> Vergleich und keine Zuweisung erwartet, so sieht es zumindest die
> Definition von if vor.

Nein. Da liegst Du falsch. if erwartet einen Ausdruck, der einen Wert 
hat. Und eine Zuweisung hat auch einen Wert.

Das ist kein syntaktischer Fehler, das ist legales C.

Allerdings ist das unüblich und wird deswegen vom gcc (und auch 
anderen Compilern) mit einer Warnung versehen.

Zeno schrieb:
> Soviel mal nur zu den Warnings. Das ist aber an dieser Stelle gar nicht
> das Thema.

Naja, du hast behauptet, Compiler (und insbesondere GCC) würden da nicht 
warnen, und das ist ganz einfach falsch.

> In meinem Post ging es darum, daß der Compiler einen klaren syntaktischen
> Fehler durchgehen läßt.

Es ist kein syntaktischer Fehler.

> In der if - Bedingung wird ein Vergleich und keine Zuweisung erwartet, so
> sieht es zumindest die Definition von if vor.

Nein. In der if-Bedinung wird etwas erwartet, das einen Wert liefert. Ob 
das ein Vergleich, eine Zuweisung, ein Funktionsaufruf oder sonst was 
ist, ist egal.

> Da nun mal das einfache = in C als Zuweisungsoperator missbraucht wird
> ist es ein klarer Fehler, wobei kein Binary erstellt werden dürfte.

Nein, denn auch ein Zuweisungsoperator liefert einen Wert und kann damit 
in einer if-Abfrage verwendet werden - ganz legal. Das wird auch gerne 
mal verwendet, um z.B. den Rückgabewert einer Funktion in einer Variable 
zu speichern und gleichzeitig zu prüfen, was vor allem in Schleifen die 
oben schon erwähnte Codeduplizierung vermeidet. Sowas wie

1

while (result = fread(buf, 1, BUFSIZE, file))

2

{

3

    // arbeite mit buf

4

}

5

6

// Fehlerbehandlung

ist eine mögliche Anwendung. Ohne die Zuweisung im while müßte man 
schreiben

1

result = fread(buf, 1, BUFSIZE, file);

2

while (result)

3

{

4

    // arbeite mit buf

5

    result = fread(buf, 1, BUFSIZE, file);

6

}

7

8

// Fehlerbehandlung

und da haben wir wieder zwei identische Funktionsaufrufe, bei denen man 
immer aufpassen muss, dass man bei der Änderung des einen auch den 
anderen anpasst.

> Fazit: Eine einfache Zuweisung in der if Bedingung ist in jedem Fall
> eine Fehlermeldung wert.

Da sie kein Fehler ist, darf ein Compiler da auch keinen Fehler melden.

Zeno schrieb:
> Für mich ist und bleibt C eine Baustelle, es wurde immer wieder was dazu
> gefrickelt, was die Unzulänglichkeiten dieser Sprache nicht beseitigt
> hat.

Bevor Du C "Unzulänglichkeiten" unterstellst, wäre es hilfreich, C zu 
lernen. Deine bisherigen Kommentare lassen diesbezüglich bei Dir noch 
viel Potential erkennen.

Am Stammtisch ist jeder sich selbst der beste Bundestrainer ...

Rufus Τ. F. schrieb:
> Allerdings ist das unüblich und wird deswegen vom gcc (und auch
> anderen Compilern) mit einer Warnung versehen.

Andersrum. Ein Assignment in der Bedingung ist ziemlich verbreitet. Aber 
weil vorsichtige Compiler
  while (n = f(...))
nicht so doll finden, schreiben die Leute mittlerweile
  while ((n = f(...)) != 0)

Zeno schrieb:
> Solche Konstrukte wie while(1), for(;;) ... gehören mindestens genau so
> an den Pranger gestellt wie goto.

Weil die Endlosschleife ja auch der typische Anwendungsfall in
einer Programmiersprache ist, dass man ihm unbedingt ein eigenes
syntaktisches Element spendieren muss?

Es wurde bereits festgestellt, dass es nur sehr, sehr wenige Sprachen
gibt, die für diesen Sonderfall ein eigenes Element vorhalten.  Aus
gutem Grund: man gibt sich normalerweise Mühe, die Anzahl der
reservierten Worte in einer Sprache nicht ausufern zu lassen.

Wenn dich das “for (;;)” wirklich so beim Lesen stört, kannst du ja
allemal ein

1

#define forever for (;;)

oder, nach Belieben

1

#define forever while (1)

irgendwo in ein Headerfile schreiben.

Zeno schrieb:
> if leitet eine Verzweigung ein und erwartet dazu als Bedingung einen
> boolschen Ausdruck.

Nein:

1

6.8.4.1 The if statement

2

Constraints

3

1

4

The controlling expression of an if statement shall have scalar type.

Da steht nichts von “Boolean”.

Zeno schrieb:
> Wenn ich aus einer Programmiersprache XY einen Großteil der
> syntaktischen Elemente, Sonderzeichen etc. übernehme, dann ist die
> neue Sprache nach meinem Verständnis schon XY lastig.

Eine Sprache besteht aber aus mehr als nur aus Syntax. Für mich ist es
zweitrangig, ob eine logische UND-Verknüpfung mit "and", ".AND.", "&"
oder "&&" geschrieben wird, entscheidend ist vielmehr, ob es diese
Operation in einer Sprache möglich ist oder nicht.

> Als schlimm empfinde ich es wenn dabei grundlegende Designschwächen
> mit übernommen werden an statt sie auszumerzen.

Nimm als Beispiel Python: Es werden im Wesentlichen die gleichen
Operatorsymbole wie in C verwendet. Der in C aus historischen Gründen
bestehende, aber häufig kritisierte Vorrang der Vergleichs- vor den
Bitoperatoren wurde in Python geändert.

> Das man hierbei Vieles von C übernommen hat ist wohl eher dem
> Bestreben geschuldet den Übergang von C zu Java einfacher zu
> gestalten.

Eben. Man muss ja das Rad nicht ständig neu erfinden. Die Aktzeptanz
neuer Sprachen steigt gewaltig, wenn die Programmierer nicht jedesmal
wieder bei Null anfangen müssen.

> Für mich ist und bleibt C eine Baustelle, es wurde immer wieder was dazu
> gefrickelt, was die Unzulänglichkeiten dieser Sprache nicht beseitigt
> hat.

Nenne mir eine Sprache, die schon eine gewisse Reife hat (also älter als
ca. 10 Jahre ist), und bei der dies nicht der Fall ist. Da dieses
Problem in ähnlicher Form auch bei natürlichen SPrachen besteht, nehme
ich an, dass das in der Natur der Sache liegt und einfach akzeptiert
werden sollte.

C ist syntaktisch nun einmal streckenweise etwas eigenwillig. Das ist 
nicht neu. Sich aber ausgerechnet über so triviales wir die Eleganz von 
for(;;) oder while(1) aufzuregen, wirkt auf mich reichlich absurd.

Jörg W. schrieb:

> Es wurde bereits festgestellt, dass es nur sehr, sehr wenige Sprachen
> gibt, die für diesen Sonderfall ein eigenes Element vorhalten.

p.s.:

https://en.wikipedia.org/wiki/Infinite_loop#Language_support

Ob das Weglassen der Bedingungen in Go (for {}) nun wirklich
übersichtlicher ist als das Weglassen des mittleren Teils in C
(for (;;) {}), halte ich schon arg für Geschmackssache.  Ein “for”
ohne Bedingung liest sich irgendwie komisch, denn in der englischen
Syntax fehlt dann was … “loop … end loop” in Ada ist eher zu
verstehen, aber halt eine völlig andere Syntax als C.  Nun ist Ada
sicher keine schlechte Programmiersprache, aber wenn man sich ihre
tatsächliche Verbreitung anschaut: irgendwas muss es sein, dass sie
nicht die allgegenwärtige Sprache in der Controllerwelt ist.

Manchmal ist halt etwas Pragmatismus der Sache durchaus förderlich.

Dass C durchaus Unzulänglichkeiten hat, wird übrigens kaum einer
bestreiten.  Diese aber nun gerade an der Syntax der Endlosschleife
festmachen zu wollen, ist einfach nur lächerlich.

Zeno schrieb:
> Das sehe ich schon richtig. if leitet eine Verzweigung ein und erwartet
> dazu als Bedingung einen boolschen Ausdruck. In der einschlägigen
> Literatur heiß es dazu

Was für eine "einschlägige Literatur" mag das sein?

Zeno schrieb:
> Ich habe dies auch begründet und dazu eine Beschreibung des if Befehls
> aus der Literatur zitiert.

Nochmal (weil's so schön ist) aus welcher Literatur?

Zeno schrieb:
> Ich habe mir das nicht aus den Fingern gezogen. Ich habe dies auch
> begründet und dazu eine Beschreibung des if Befehls aus der Literatur
> zitiert.

Die Unzulänglichkeit des Autors dies richtig zu Beschreiben und deine 
Unzulänglichkeit dies zu Verstehen, kannst du aber nicht als 
Unzulänglichkeit von C auslegen.

Für C gibt es einen gültigen Standard. Der ist Entscheidend.

1:
Zeno schrieb:
> Ach ja: Diese -> Schreibweise ist auch wieder so ein C++ Krampf der sich
> erst mal einem erschließen muß. Bei C# nimmt man übrigens wieder einen .
> für so was, wie in anderen Programmiersprachen auch.

2:
Zeno schrieb:
> Fazit: Eine einfache Zuweisung in der if Bedingung ist in jedem Fall
> eine Fehlermeldung wert.

An Deiner Stelle würde ich einfach die Klappe halten und still mitlesen. 
Steht Dir besser und Du kannst vielleicht noch etwas lernen. Deine 
unqualifizierten Äußerungen, die lediglich pure Unkenntnis von der 
Materie verraten, machen diesen Thread leider nicht lesbarer. Ganz im 
Gegenteil.

Zeno schrieb:
> Ach ja: Diese -> Schreibweise ist auch wieder so ein C++ Krampf der sich
> erst mal einem erschließen muß.

Ein C Krampf. Aber Krampf ist es, das stimmt. Der Kernfehler lag 
freilich woanders: die Dereferenzierung als Präfix- statt 
Postfix-Operator zu definieren. Der -> Operator ist nur die Konsequenz.

Huh schrieb:
> Der eine stellt "while(1)" an den Pranger, der andere "for(;;)". Und
> "goto" ist sowieso für alle "bäh". Jetzt kommst du und willst alle drei
> Varianten nicht. Was bleibt dann noch übrig für eine Endlosschleife?
> Diesen Vorschlag, wie man es nun richtig macht, hast du vergessen!

Ich werde mal für ihn einspringen:

Die Lösung aller Endlosschleifenprobleme und damit die Quintessenz
dieses Threads heißt:

                         Endrekursion

Dazu braucht man keine spezielle Syntax, über die sich jemand aufregen
könnte, keine "entarteten" Konstrukte, kein Goto, sondern lediglich
Funktionsaufrufe, deren Syntax aber allgemein akzeptiert zu sein
scheint.

Beispiel:

1

#include <stdio.h>

2

3

void loop(void) {

4

  printf("loop\n");

5

  loop();

6

}

7

8

int main(void) {

9

  loop();

10

  return 0;

11

}

So genau macht man das und nicht anders.

Eigentlich könnte der Thread jetzt geschlossen werden. Ich tue es nur
deswegen nicht, weil die Diskussion gerade so lustig ist ;-)

Zeno schrieb:
> Du hast bisher nichts zur Diskussion beigetragen [...]

Ich hatte zunächst unter meinen Beitrag auch noch die Begründungen 
geschrieben, warum Deine Äußerungen 1) und 2) absoluter Unsinn sind. 
Aber ich habs mir dann doch verkniffen und die Zeilen wieder gelöscht.

Dann zum Inhalt:

zu 1: Neben dem Operator "->" in C/C++ gibt es auch den Operator ".". 
Aus Deinem Beitrag wird klar, dass Du den Unterschied der Bedeutung 
nicht kennst, sonst würdest Du "->" in C++ nicht mit dem Operator "." in 
C# vergleichen.

zu 2: Eine Zuweisung in einer if-Bedingung ist in C ausdrücklich 
erlaubt. Würde der C-Compiler hier eine Fehlermeldung ausgeben, wäre das 
ein Bug - und zwar im Compiler. Allerhöchstens eine Warnung wäre 
angebracht, mehr aber auf keinen Fall.

Beide Äußerungen disqualifizieren Dich leider an der Teilnahme. Die 
Tatsache, dass Dir das Ganze überhaupt noch nichtmals peinlich ist, 
unterstützt den Eindruck, dass hier ein Blinder über Farben diskutieren 
will.

Und nun zum Vorwurf, ich würde mich nicht an der Diskussion beteiligen: 
Es gibt hier keinen Beitragszwang. Den solltest Du doch öfter auch mal 
beherzigen.

Zeno schrieb:
> Alle anderen außer Dir sind blööd - so kann man es natürlich auch sehen.

Was ich oben zitiert habe, ist der Standard, der die
Programmiersprache C beschreibt.  Da steht eben nun einmal nichts
von einem „Booleschen Ausdruck“ oder dergleichen.  Wenn andere das
in der Literatur so beschreiben, kannst du nicht nur aufgrund deren
Beschreibung daherkommen und verlangen, dass ein Compiler für
irgendwas einen Fehler auszuspucken hätte.  Hat er nicht, darf er
nicht.

Wenn dir diese sprachliche Eigenheit (und andere) von C nicht
gefallen, dann nimm diese Sprache doch besser nicht, aber mach
dich nicht öffentlich lächerlich.  Es gibt Dinge in C, die viel
mehr zu kritisieren wären als das.

Zeno schrieb:

> Es wird hier aber genug Leute geben die wieder was zu meckern haben.

Beispielsweise der übergelaufene Stack deines Prozessors.