gcc: operation on may be undefined

In Java wäre das wohl ok. In C isses undefiniert, da niemand weiß, wann 
der um 1 erhöhte Wert wieder an die Variable zurückgeht.
Ein Übersetzer könnte etwa folgendes draus machen:

1

     G_OpData.TravelCnt[tCnt][tDir] =    tBuf[tIdx]

2

                                      + (tBuf[tIdx] << 8)

3

                                      + (tBuf[tIdx] << 16)

4

                                      + (tBuf[tIdx] << 24);

5

tIdx += 4;

Es fehlt ein Sequenzpunkt dazwischen. Ansonsten halte ich auch wenig von 
solchen Spielereien.

Lösung:

1

     G_OpData.TravelCnt[tCnt][tDir] =    tBuf[tIdx + 0]

2

                                      + (tBuf[tIdx + 1] << 8)

3

                                      + (tBuf[tIdx + 2] << 16)

4

                                      + (tBuf[tIdx + 3] << 24);

5

tIdx += 4;

Übersichtlich und jeder verstehts, ohnes Gehirn zu verknoten.

> Es hat wohl mit dem Post-Inkrement zu tun. Trotzdem finde ich, dass das
> so in Ordnung ist.

Ob du das findest, ist aber dem Compiler egal. ;-)
Wie Sven schreibt, fehlt ein Sequenzpunkt zwischen den Inkrements. Das 
Verhalten von Code, der eine Variable mehrmals ändert oder ändert und 
liest, ohne daß dazwischen ein Sequenzpunkt liegt, ist in C undefiniert. 
Daher zurecht die Warnung.

A. K. schrieb:
> Sven P. schrieb:
>
>> In Java wäre das wohl ok.
>
> Wie ist das denn in Java definiert?
Keine Ahnung, ich erinnere mich nur an so ein hirnverbranntes Beispiel 
für Java, und der Compiler hat keine Warnung ausgespuckt.

Hier isses:
http://www.thestudentroom.co.uk/showthread.php?t=639421
In C/++ wäre das hochgradig undefiniert und totaler Schwachsinn isses 
sowieso.

Hi, ich habe letzte Nacht kaum geschlafen, die Heizung war kaputt, hab 
seit 7 Uhr Handwerker im Haus, die die Eingangstür wechseln - und Kaffe 
ist das einzige was mich jetzt noch am leben hält ;-) Vielleicht liegt 
es ja daran, dass ich total auf den Schlauch stehe und das Problem nicht 
nachvollziehen kann.
Mein gcc (version 3.4.5 (mingw-vista special)), aufgerufen mit -Wall, 
meckert auf jedenfall nicht. Welche gcc version für welches Target mit 
welchen compiler flags benutzt Du denn? Und wieso ist das Verhalten 
undefiniert? Gibt es deswegen nicht auch die C-Prioritäten? IMHO steht 
da doch: Greife auf das Array tBuff mit dem Index tIdx zu, danach 
inkrementiere tIdx, danach greife auf das Array tBuff mit dem neuen Wert 
von tIdx zu, danach inkrementiere tIdx, danach addiere die Inhalte der 
ersten beiden Array zugriffe usw.

Grüße Daniel

Daniel H. schrieb:
> IMHO steht
> da doch: Greife auf das Array tBuff mit dem Index tIdx zu, danach
> inkrementiere tIdx, danach greife auf das Array tBuff mit dem neuen Wert
> von tIdx zu, danach inkrementiere tIdx, danach addiere die Inhalte der
> ersten beiden Array zugriffe usw.
Ne, es steht nirgendwo, WANN tIdx seinen neuen Wert bekommt. Dafür gibts 
ja Sequenzpunkte, und die fehlen hier.

Danke an alle! Jetzt habe auch ich es geschnallt :-)

Bei a = b + b++; kann das Inkrement z.B vor oder nach der Addition 
erfolgen, was natürlich zu unterschiedlichen Verhalten führt. Sicher ist 
nur, dass b nach dieser Zeile inkrementiert wurde.

Grüße, Daniel

Das wiederum ist dann nicht mit der Kurzschluss-Bewertung zu 
verwechseln, bei welcher die Auswertereihenfolge festgelegt ist:

1

if ( foo() && bar() ) {

2

3

}

4

5

if ( foo() || bar() ) {

6

7

}

In beiden Fällen wird foo() zuerst bewertet. Dadurch lassen sich solche 
Sachen formulieren:

1

Zeiger p;

2

if ( (p != NULL) && (p->bla) ) ..

> if ( foo() && bar() ) {
>
> }
>
> if ( foo() || bar() ) {
>
> }
>
>
> In beiden Fällen wird foo() zuerst bewertet.

Deshalb stellen in C das && und das || auch Sequenzpunkte dar.

> Dadurch lassen sich solche
> Sachen formulieren:
> Zeiger p;
> if ( (p != NULL) && (p->bla) ) ..

Theretisch geht sogar das::

1

  p && p->x++ || printf("Kein p\n");

(zugegebenermaßen arg konstrukiert)

Achso, dabei am Rande ein Zitat:

Die Programmiersprache C. Ein Nachschlagewerk.
Regionales Rechenzentrum für Niedersachsen/Leibniz-Universität Hannover, 
Zentralinstitut für angewandte Mathematik, Forschungsgruppe Jülich GmbH:

Dieses Institut hat so ein grünes Heftchen herausgebracht und freut 
sich:
17. unveränderte Auflage, September 2008.
Auflabe: bisher 163.000 Exemplare.

Und in jedem dieser Exemplare steht auf Seite 77 unten:

1

int i, j;

2

/* ... */

3

4

i = 1;

5

i = ++i + 1; /* dies ist auch möglich; i hat Wert 3 */

Rolf Magnus schrieb:
>

1

>   p && p->x++ || printf("Kein p\n");

2

>

> (zugegebenermaßen arg konstrukiert)

Garnicht mal. Frag mal Perl-Leute, oder benutz ne anständige Konsole:

1

cc -o test test.c && ./test

Ja, is natürlich ein klasse Beispiel für so ein Nachschlagewerk.

Genauso schön wie (sinngemäß):

1

char c;

2

while ( (c = getc(f)) != EOF) ..

>>
>>   p && p->x++ || printf("Kein p\n");
>>
>> (zugegebenermaßen arg konstrukiert)
>
> Garnicht mal. Frag mal Perl-Leute, oder benutz ne anständige Konsole:
> cc -o test test.c && ./test

Ist mir schon klar. In Shellskripten ist das recht üblich.
Aus einem Makefile, das ich letzte Woche schrieb:

1

        @decompyle --verify -o $(dir $<) $< > $(patsubst %.pyc,%.log,$<) 2>&1 && echo ok || ( [ $$? -eq 3 ] && echo verify failed || echo failed; true)

Ich meinte, daß es für C eher konstruiert ist. Da ergibt sich bei dieser 
Art der Verwendung von Operatoren nämlich das Problem, daß sich in C 
nicht jeder Ausdruck als logischer Wert verwenden läßt. Das Beispiel 
klappt nur, weil p->x ein int ist, printf einen int zurückgibt und p 
sich in einen konvertieren läßt.

1

p && p->flag || (something_returning_void("Flag kaputt"), 1);

schmunzel

> i = ++i + 1; /* dies ist auch möglich; i hat Wert 3 */

Bevor ihr alle zu sehr über dieses Beispiel lästert: Kann jemand eine
Auswertereihenfolge angeben, bei der am Ende nicht 3 herauskommt? Mir
fällt spontan jedenfalls keine ein und bin deswegen fast überzeugt, dass
dieser Code nicht undefined ist.

"Fast" deswegen, weil ich noch nicht lange genug überlegt habe ;-)

> Mir fällt spontan jedenfalls keine ein und bin deswegen fast
> überzeugt, dass dieser Code nicht undefined ist.

Nehme alles zurück, da exakt dieses Beispiel im ISO-Standard als
Beispiel für einen undefinierten Ausdruck angegeben ist :)

> i = ++i + 1;

++i wird zu 2 ausgewertet, also steht da:

i = 2 + 1;

Danach könnte das i = i + 1 ausgeführt werden.

==> i = 4;

A. K. schrieb:
> i = 1;
> temp = i + 1;
> i = temp + 1;
> i = temp;

Ja, genau, das wäre das Gegenbeispiel.

yalu schrieb:
>> i = ++i + 1; /* dies ist auch möglich; i hat Wert 3 */
>
> Bevor ihr alle zu sehr über dieses Beispiel lästert: Kann jemand eine
> Auswertereihenfolge angeben, bei der am Ende nicht 3 herauskommt?

1

i = 1;

2

3

zwischen = i + 1;

4

i = zwischen + 1;

5

i = zwischen;

6

7

/* i ist 2 */

>> i = ++i + 1; /* dies ist auch möglich; i hat Wert 3 */
>
> Bevor ihr alle zu sehr über dieses Beispiel lästert: Kann jemand eine
> Auswertereihenfolge angeben, bei der am Ende nicht 3 herauskommt?

Spielt eigentlich keine Rolle. Laut ISO-C braucht i danach gar keinen 
Wert zu haben. Das Programm darf an der Stelle auch einfach 
stehenbleiben oder danach beliebigen Blödsinn veranstalten. Nicht der 
Wert gilt als undefiniert, sondern das gesamte Verhalten des Programms.

> Mir fällt spontan jedenfalls keine ein und bin deswegen fast überzeugt,
> dass dieser Code nicht undefined ist.

Er könnte z.B. beim Operator++ den inkrementierten Wert zurückgeben, da 
1 dazuzählen und an i zuweisen. Danach wird dann das vorher gemerkte 
Ergebnis vom Operator++ nach i geschrieben. Dann steht danach 2 in i.

A. K. schrieb:
> temp = i + 1;
> i = temp + 1;
> i = temp;

Sven P. schrieb:
> zwischen = i + 1;
> i = zwischen + 1;
> i = zwischen;

@Sven P.: Danke für die Übersetzung des Codes von A. K. ins Deutsche.
Spätestens jetzt habe ich's wirklich kapiert ;-)

> while ( (c = getc(f)) != EOF) ..

öhm...  grübel *denk*

Wenn ich mal ganz kleinlaut fragen darf, was stimmt mit dem Beispiel 
nicht? ;)

> Wenn ich mal ganz kleinlaut fragen darf, was stimmt mit dem Beispiel
> nicht? ;)

Da stimmen zwei Sachen nicht. Eine in dem Teil, den du zitiert hast, 
eine im anderen Teil.

getc() gibt einen Integer zurück oder ein Zeichen. (c = getc(..)) ist 
wegen c vom Typ char. Dadurch kann EOF (-1) nicht mehr vom Zeichen #255 
unterschieden werden.

Karl:
An deinem Beispiel ist mir grad nicht klar, was schief gehen soll --

Sven P. schrieb:
> getc() gibt einen Integer zurück oder ein Zeichen. (c = getc(..)) ist
> wegen c vom Typ char. Dadurch kann EOF (-1) nicht mehr vom Zeichen #255
> unterschieden werden.

AHA! Das hab ich doch glatt übersehen.

Sven P. schrieb:
> Karl:
> An deinem Beispiel ist mir grad nicht klar, was schief gehen soll --

Ich könnte mir höchstens vorstellen, dass das EOF-Flag noch nicht 
gesetzt ist, wenn eine leere Datei geöffnet wird. Und damit wird die 
Schleife trotzdem einmal ausgeführt, obwohl nichts gelesen werden kann.

Zitat:
> This indicator is generally set by a previous operation on the stream that > 
reached the End-of-File.

> Karl:
> An deinem Beispiel ist mir grad nicht klar, was schief gehen soll --

feof(f) wird erst wahr, nachdem man versucht hat, über das Dateiende 
hinaus zu lesen. Die Schleife wird also einmal zu oft durchlaufen.

Hier ist ein Beispiel mit einer etwas asführlicherer Erklärung:

http://www.cprogramming.com/faq/cgi-bin/smartfaq.cgi?answer=1046476070&id=1043284351

Achso, die Schiene ist gemeint.

Die Warnung selber ist eigentlich auch amüsant:

"warning: operation on `blubb' may be undefined"

Wieso "may be"? Gemäss Standard ist das Verhalten undefiniert.

Naja, der Standard sagt, es ist undefiniert. Das hindert aber niemanden, 
der einen Compiler baut, es in irgendeiner Weise zu festzulegen. Im 
Standard steht ja nicht 'must be undefined'.

Sven P. schrieb:
> Im
> Standard steht ja nicht 'must be undefined'.

Genau, der Compiler muss in dem Fall, wenn er standardgemäß arbeiten 
soll, eine zufällige binäre Sequenz in den Code einbauen ;)

> Wieso "may be"? Gemäss Standard ist das Verhalten undefiniert.

Ich nehme an, daß die Erkennung dieses Falls nicht 100% zuverlässig ist, 
da sie doch schon ziemlich extensive Analyse des Codeflusses erfordert. 
Es könnte also einen Fall geben, in dem die Warnung kommt, obwohl alles 
in Ordnung ist. Deshalb "may be".

> Das hindert aber niemanden, der einen Compiler baut,
> es in irgendeiner Weise zu festzulegen.

Und was hat er davon? Gar nichts, ausser zusätzlichen Implementations- 
und Dokumentationsaufwand, weil der nächste Compiler folgende Variante 
implementiert hat:

> Genau, der Compiler muss in dem Fall, wenn er standardgemäß arbeiten
> soll, eine zufällige binäre Sequenz in den Code einbauen

So gesehen ist der Wortlaut "is undefined" das einzig Vernünftige. Wenns 
mir mal langweilig genug ist, schreib ich einen Bugreport.

Bartli schrieb:
>> Das hindert aber niemanden, der einen Compiler baut,
>> es in irgendeiner Weise zu festzulegen.
>
> Und was hat er davon? Gar nichts, ausser zusätzlichen Implementations-
> und Dokumentationsaufwand, weil der nächste Compiler folgende Variante
> implementiert hat:
Du kannst davon ausgehen, dass fast jeder Compiler es in irgendeiner 
Weise definiert. Nur die allerwenigsten werden bei solch einer 
Konstruktion einen Zufallsgenerator bemühen.

Ansonsten schließe ich mich Rolf Magnus an.

> Du kannst davon ausgehen, dass fast jeder Compiler es in irgendeiner
> Weise definiert.

Nee, definitiv nicht. Aufgrund ihrer Implementation dürften die meisten 
Compiler ein deterministisches Verhalten haben, aber du glaubst doch 
nicht im Ernst das da jemand hingeht, sich zuerst überm ganzen Problem 
den Kopf zerbricht und dann erst das Verhalten definiert und 
dokumentiert?

Bartli schrieb:
>> Du kannst davon ausgehen, dass fast jeder Compiler es in irgendeiner
>> Weise definiert.
>
> Nee, definitiv nicht. Aufgrund ihrer Implementation dürften die meisten
> Compiler ein deterministisches Verhalten haben, aber du glaubst doch
> nicht im Ernst das da jemand hingeht, sich zuerst überm ganzen Problem
> den Kopf zerbricht und dann erst das Verhalten definiert und
> dokumentiert?
Nö, hab ich das behauptet? Aber du siehst ja, die Java-Leute haben sich 
zuerst den Kopf darüber zerbrochen und das Verhalten dann fest 
definiert.

Laut C-Standard musst du auch damit rechnen, dass ein char 43 Bits hat, 
davon aber 13 Bits nicht zum Wert gehören. Ein Zeiger ist dann 7 chars 
breit und ein Funktionszeiger darf auch 5mal so groß sein, wie ein 
Datenzeiger. Außerdem sind char, short, int und long alle gleichbreit.

Und? Das wäre eine vollkommen Standard-C-Konforme Umgebung.

Schön, Sven. Und jetzt?

Trotzdem glaube ich nicht, dass gcc's Implementation auf eine bewusst 
definierte Art arbeitet, und die Formulation "may be" ist und bleibt 
Quark.

Was anderes ist es im Fall von "blah may be used uninitialized", aber 
darum gehts nicht, ebenso wenig um 47 Bits breite chars.

Und was Java betrifft: da gabs noch keine Altlasten in Form von 
Compilern die lange vor irgendwelchen Standards existierten. Da hat sich 
die Mühe das Zeugs vorwegs zu definieren sogar gelohnt.

> Laut C-Standard musst du auch damit rechnen, dass ein char 43 Bits hat,
> davon aber 13 Bits nicht zum Wert gehören.

Nicht ganz. Bei char müssen alle Bits zum Wert beitragen.

> Ein Zeiger ist dann 7 chars breit und ein Funktionszeiger darf auch 5mal
> so groß sein, wie ein Datenzeiger. Außerdem sind char, short, int und
> long alle gleichbreit.
>
> Und? Das wäre eine vollkommen Standard-C-Konforme Umgebung.

Ja. Wenn das auf der Zielplattform sinnvoll wäre, warum auch nicht?