Was macht der compiler aus sprintf(s,"%u %u",a,a++);

a++ ist der Postfixoperator. Erst wird der Wert verarbeitet, dann 
inkementiert.
++a ist der Prefixoperator. Der Wert wird erst inkrementiert und dann 
verarbeitet.

Da die Elemente von rechts nach links auf den Stack gelegt werden ist 
die Ausgabe nunmal "2 1".

Sebihepp schrieb:
> Da die Elemente von rechts nach links auf den Stack gelegt werden

?!? Wirklich?


ich dachte, dass wenn ich in printf formatierte ausgaben in den string 
packe "von links nach rechts" dann werden die zugehörigen Argumente auch 
"von links nach rechts" angegeben, genauso auch die Ausgabe...

lag ich da falsch? Ich denke nicht oder? Das mit dem post oder präfixop. 
kenne ich. Aber die umgekehrte Reihenfolge hab ich immer noch nicht
verstanden...

> Was macht der compiler aus sprintf(s,"%u %u",a,a++);

Der macht sich einen Spaß draus. Das läuft unter "undefined bahaviour".

Peter Dannegger schrieb:
> Der Kommaoperator muß den Wert des letzten Ausdrucks zurückgeben.
> Aber wann er die Ausdrücke berechnet, ist undefiniert.

sprintf(s,"%u %u",a,a++);

aber hierbei handelt es sich doch nicht um ein Kommaoperator oder etwa 
doch?

Peter schrieb:
> aber hierbei handelt es sich doch nicht um ein Kommaoperator oder etwa
> doch?

Nein.

Timo P schrieb:
> ich dachte, dass wenn ich in printf formatierte ausgaben in den string
> packe "von links nach rechts" dann werden die zugehörigen Argumente
> auch "von links nach rechts" angegeben, genauso auch die Ausgabe...
>
> lag ich da falsch?

Ja. Die Reihenfolge ist in C nicht spezifiziert. Mit anderen Worten: Du 
darfst von keiner spezifischen Reihenfolge ausgehen, da das jeder 
Compiler tun kann, wie er will.

Simon Budig schrieb:
> Die Reihenfolge, in der die Funktionsargumente ausgewertet werden
> (bevor die Funktion dann aufgerufen wird) ist meines Wissens
> undefiniert.

-pedantic: Nicht undefiniert, sondern unspezifiziert.

Sebihepp schrieb:
> Da die Elemente von rechts nach links auf den Stack gelegt werden ist
> die Ausgabe nunmal "2 1".

Das ist systemspezifisch.

Das war zumindest früher nicht spezifiziert.
Ich kenne einen Fall, daß durch so ein Konstrukt:
(if ((*pc++ == '0') && (*pc == '0'))
locker 120.000 DM Schaden entstanden sind. Wurde von MSC 5.0 so 
übersetzt wie gewünscht, MSC 6.0 hat dann aber leider den increment nach 
hinten gezogen. Dadurch wurde 2 mal das erste Zeichen verglichen.
Pech daß diese 2 Zeichen der Returncode der Authorisierungszentrale für 
eine Reihe von Geldautomaten waren und die dann munter ausgezahlt hat 
weil er '00' verstanden hat (auszahlen) aber tatsächlich '04' kam (Karte 
einziehen, Manipulationsverdacht).
Eine Bande hatte das spitz gekriegt und munter mit geklauten Karten die 
längst gesperrt waren Kohle abgehoben.

U.R. Schmitt schrieb:
> Das war zumindest früher nicht spezifiziert.
> Ich kenne einen Fall, daß durch so ein Konstrukt:
> (if ((*pc++ == '0') && (*pc == '0'))
> locker 120.000 DM Schaden entstanden sind. Wurde von MSC 5.0 so
> übersetzt wie gewünscht, MSC 6.0 hat dann aber leider den increment nach
> hinten gezogen. Dadurch wurde 2 mal das erste Zeichen verglichen.
> Pech daß diese 2 Zeichen der Returncode der Authorisierungszentrale für
> eine Reihe von Geldautomaten waren und die dann munter ausgezahlt hat
> weil er '00' verstanden hat (auszahlen) aber tatsächlich '04' kam (Karte
> einziehen, Manipulationsverdacht).
> Eine Bande hatte das spitz gekriegt und munter mit geklauten Karten die
> längst gesperrt waren Kohle abgehoben.

Hast du dafür eine Quelle? Das wäre ein prima Beispiel für "sauberes 
Programmieren". Hätte man *pc==0 && *(pc+1)==0 geschrieben wäre alles 
gut gegangen.

U.R. Schmitt schrieb:
> Ich kenne einen Fall, daß durch so ein Konstrukt:
> (if ((*pc++ == '0') && (*pc == '0'))
> locker 120.000 DM Schaden entstanden sind. Wurde von MSC 5.0 so
> übersetzt wie gewünscht, MSC 6.0 hat dann aber leider den increment nach
> hinten gezogen.

Dann war ein Bug in MSC 6.0 oder an dieser Geschichte stimmt etwas 
nicht. Ich sehe nicht, wie hier das Inkrement nach hinten (wohin?) 
gezogen werden könnte.

doch g schrieb:
> Hast du dafür eine Quelle? Das wäre ein prima Beispiel für "sauberes
> Programmieren". Hätte man *pc==0 && *(pc+1)==0 geschrieben wäre alles
> gut gegangen.

Wenn schon, dann "pc[0]==0 && pc[1]==0". Davon abgesehen rettet einen 
sauberes Programmieren auch nicht vor Bugs im Compiler.

Die Bindungsstärken sind zwar eindeutig bei *pc++, aber *(pc++) ist 
deutlicher - (*pc)++ soll es ja nicht sein.

Oder so:

if (*(pc++) == 0)
  if (*pc == 0)
    ...

Hier wird auch ersichtlich, dass nur die erste Anweisung unbedingt 
ausgeführt wird. Das kann in verketteter Logik m. E. genauso passieren. 
Ein weiteres ++ sollte man sich dann besser verkneifen, außer, man 
braucht pc hinterher nicht mehr.

df1as schrieb:
> Oder so:
>
> if (*(pc++) == 0)
>   if (*pc == 0)
>     ...
>
> Hier wird auch ersichtlich, dass nur die erste Anweisung unbedingt
> ausgeführt wird. Das kann in verketteter Logik m. E. genauso passieren.

Ein Programm leserlich zu schreiben ist eine Sache, aber als "Publikum" 
sollte man diejenigen anpeilen, die von C mindestens eine grundlegende 
Ahnung haben. Auf logische Operatoren wie && und || zu verzichten nur 
weil ein C-unbefleckter die nicht verstehen könnte geht definitiv zu 
weit.

Und bei Verzicht auf diese Operatoren kommt bei allem ausser trivialen 
Bedingunen eine Wust von verschachtelten ifs raus und damit das 
Gegenteil von leserlich.