Warum heutige C-Programmierer so ineffizient sind!

Ich zähle mich gerne zu solchen Leuten ("for(;;)" braucht nur 7).
Die meisten Ideen sind zwar nicht brauchbar, aber hin und wieder tauchen 
interessante Lösungsansätze auf.

Also zumindest bei guten Compilern gilt, dass man ihm durchaus zumuten 
kann, solche Trivialsachen zu optimieren:

http://media.ccc.de/browse/conferences/camp2007/cccamp07-en-1952-Know_your_compiler.html

Die Probleme bei C liegen ganz wo anders. Zum Beispiel darin, dass eine 
Funktion mehrere Rücksprungadressen haben kann.

Beispiel:

void irgendwas(){
...
}

int main(){
   a();
   b();
   irgendwas();
   c();
   d();
   e();
}

Da kann der Compiler nicht bestimmen, wohin "irgendwas" zurückspringt, 
da in "irgendwas" die Rücksprungadresse geändert werden kann. (machen 
sehr viele C-Programmierer!) Somit müssen bei ISRs alle Register 
gespeichert werden.

Christian Berger schrieb:

> Da kann der Compiler nicht bestimmen, wohin "irgendwas" zurückspringt,
> da in "irgendwas" die Rücksprungadresse geändert werden kann. (machen
> sehr viele C-Programmierer!)

Hättest Du bitte ein Beispiel dafür?

Einen vorgesehenen Weg gibt es für die Änderung der Rücksprungadresse 
nicht. Zwar machen das zwar tatsächlich viele Programmierer, allerdings 
eher unfreiwillig in Form von Buffer Overflows.

A. K. schrieb:
> Einen vorgesehenen Weg gibt es für die Änderung der Rücksprungadresse
> nicht. Zwar machen das zwar tatsächlich viele Programmierer, allerdings
> eher unfreiwillig in Form von Buffer Overflows.

Sag mir mal eines, wenn Buffer Overflows seit Jahrzehnten bekannt sind, 
und ein Programmierer programmiert so was, wie willst Du feststellen, ob 
er das mit Absicht oder aus Versehen gemacht hat? Wie soll das der 
Compiler feststellen? Somit muss der Compiler auf der sicheren Seite 
sein, und alle Register bei einer ISR weg speichern.

Nebenbei gibts natürlich einen definierten Weg die Rücksprungadresse zu 
überschreiben. Man greift auf ein zu hohes Element eines lokalen Arrays 
zu. Der Offset den man braucht hängt natürlich vom Compiler ab, aber C 
war ja noch nie portabel. Der Wertebereich eines int hängt ja auch vom 
Compiler und der Plattform ab.

Christian Berger schrieb:

> Nebenbei gibts natürlich einen definierten Weg die Rücksprungadresse zu
> überschreiben.

definiert würde ich das nicht nennen.

Es gibt auch Prozessoren, die den Callstack vom Datenstack streng 
getrennt haben.
Nur weil etwas auf deinem Prozessor genau so funktioniert, heißt das 
noch lange nicht, dass das in C so vorgesehen ist. Als Faustregel kann 
man sagen: Alles was auch nur irgendwie nach Hardwareabhängigkeit 
stinkt, ist von C nicht definiert, sondern es wird dem konkreten 
Compiler überlassen, wie er das implementiert. Das hat Nachteile, weil 
einige Sachen ganz einfach nicht so streng definiert sind, wie man sich 
das als Anwendungsprogrammierer gerne wünschen würde. Hat aber auch 
Vorteile, weil dann ein Compiler nicht esoterische Features eines 
anderen Prozessors aufwändig nachbilden muss sondern sich ganz darauf 
konzentrieren kann, seinen Zielprozessor möglichst gut zu benutzen.

Der C Standard definiert, wie sich ein Programm verhalten muss, nicht 
jedoch wie dieses Verhalten zu implementieren ist.

Und C Programme sind zum größten Teil deswegen so ineffizient, weil 
der/die Programmierer ihr Handwerkszeug nicht mehr von der Pieke auf 
lernen wollen. Schau dich hier im Forum um. Auf jede 3.te C Frage müsste 
man im Grunde antworten: Kauf dir ein C-Buch, das steht da alles 
drinnen.

Rosa-Kleidchen schrieb:

> Hier reden viele vom C-Standard. Welcher denn? K&R-C?? ANSI-C?? ISO-C??
> C99?? Whatever-C???

C99 ist der letzte ISO/ANSI - C Standard.
Eventuell kann man noch die C-Version von davor nehmen, in den C 
Kernbereichen hat sich da ja nichts geändert. Aber K&R-C ist schon lange 
tot, rest in peace but please rest.

Rosa-Kleidchen schrieb:
> Ich bin nunmehr seit 20 Jahren mit C unterwegs und
> ich kenne keinen, der ernsthaft die Rücksprungadresse innerhalb der
> Funktion verändert.

naja, gelegentlich macht mal jemand ein immerhin legales 
setjmp()+longjmp().

Ob man das empfehlen will, steht auf einem anderen Blatt.

Karl Heinz Buchegger schrieb:
> Christian Berger schrieb:
>
>> Nebenbei gibts natürlich einen definierten Weg die Rücksprungadresse zu
>> überschreiben.
>
> definiert würde ich das nicht nennen.

Vielleicht immerhin "reproduzierbar" :-)

Christian Berger schrieb:

> Somit muss der Compiler auf der sicheren Seite
> sein, und alle Register bei einer ISR weg speichern.

Der Compiler muss undefiniertes Verhalten nicht berücksichtigen. 
Register sichert er in einer ISR je nachdem ob sie verwendet werden, 
wenn er das weiss, oder mindestens alle temporären Register, wenn er das 
aufgrund von Funktionsaufrufen nicht weiss. Aber vorsätzliche Buffer 
Overflows wird er dabei nicht berücksichtigen.

Gibts tatsächlich eine signifikaten Anzahl Programmierer, die 
vorsätzlich Buffer Overflows verwenden um die Rücksprungadresse ihres 
eigenen Programms zu manipulieren? Ich kenne das nur als unfreiwillige 
Kooperation. Der eine baut unabsichtlich oder fahrlässig den Buffer 
Overflow rein und der andere (Black Hat) nutzt ihn aus.

> Nebenbei gibts natürlich einen definierten Weg die Rücksprungadresse zu
> überschreiben.

Nein, den gibt es nicht, weil dieser Weg vollständig undefiniert ist. 
Die Rücksprungadresse muss auch nicht auf dem Stack liegen. Der Umstand, 
dass es bei einer bestimmten Plattform mit einer bestimmten 
Compilerversion funktioniert, macht es nicht zum definierten Verhalten.