ARM-GCC versteht den Witz nicht.

Walter T. schrieb:
> Das erzeugt zwei Fragen:
>  a) Warum spart sich der Compiler das Schachteln der Zeichenketten in
> -O3? Ich kann durch das Schachteln keine Strafe auf die Geschwindigkeit
> erkennen.
>  b) Warum kann der Compiler den konstanten Ausdruck auf der rechten
> Seite nicht auswerten und wegoptimieren? Zumindest bei -Os hat er doch
> erkannt, dass die Differenz immer 4 ist?

Die für mich relevante Frage samt Antwort fehlt. Was erwartest du als 
Ergebnis?

Walter T. schrieb:
> mh schrieb:
>> Was erwartest du als
>> Ergebnis?
>
> "Implementation defined behaviour"

Der gcc mit Wall sagt undefined. Warum sollte es auch implementation 
defined sein?

Walter T. schrieb:
>> Was erwartest du als Ergebnis?

> "Implementation defined behaviour"

Bitte konkreter: was erwartest, und warum? Was wäre denn für dich in 
diesem Fall "defined behaviour" oder (wenn es keine solche Definition 
gibt) wie würdest du das Soll-Verhalten definieren wollen?

Meiner Meinung nach ist die Codezeile sinnloser Bullshit den keine Regel 
von C beschreibt.

Walter T. schrieb:
> Hallo
> versteht den Witz nicht...

...dann solltest du nicht in C programmieren.
"Denn sie wissen nicht, was sie tun"

> Das erzeugt zwei Fragen:
> a) Warum spart sich der Compiler das Schachteln der Zeichenketten in
> -O3? Ich kann durch das Schachteln keine Strafe auf die Geschwindigkeit
> erkennen.

Der String ist nicht mehr aligned und Zugriffe drauf evtl langsamer.

> b) Warum kann der Compiler den konstanten Ausdruck auf der rechten
> Seite nicht auswerten und wegoptimieren? Zumindest bei -Os hat er doch
> erkannt, dass die Differenz immer 4 ist?

Bei zwei unabhängigen Strings vergibt erst der Linker die Adressen.

foobar schrieb:
> Bei zwei unabhängigen Strings vergibt erst der Linker die Adressen.
Die Strings sind nicht zwingend "unabhängig". Der Compiler/Linker darf 
die letzte das Ende von "100" als "0" benutzen. Das ist das unspecified 
Verhalten, dass hier schon genannt wurde. Wenn der Compiler/Linker das 
nicht macht, ist das Verhalten undefined, weil die beiden Pointer nicht 
in das selbe Objekt (Array-of-char) zeigen.

Andreas M. schrieb:
> Wie kommst Du darauf, das die Differenz "4"

Tippfehler. Das Listing hatte mich irritiert.

foobar schrieb:
> Der String ist nicht mehr aligned und Zugriffe drauf evtl langsamer.

Das klingt plausibel.

foobar schrieb:
> Bei zwei unabhängigen Strings vergibt erst der Linker die Adressen.

Das auf den ersten Blick nicht: Wenn der Compiler die Strings 
schachtelt, ist die Bedingung immer erfüllt, egal wie der Linker ihn 
schiebt. Wenn nicht, nie. Aber okay. Der Compiler hat in der abstrakten 
Maschine nichts mit den Adressen zu schaffen.

Ob LTO etwas an der Situation ändert?

Walter T. schrieb:
> mh schrieb:
>> Der gcc mit Wall sagt undefined.
>
> Meiner sagt übrigens "unspecified behavior", also der schmale Grat
> zwischen implementation defined und undefined, auf dem ich gefühlt noch
> nie zuvor spaziert bin.

Ja er sagt unspecified, ich habe gelesen, was ich erwartet habe. Und 
implementation defined ist nochmal was anderes. Es ist unspecified, weil 
der Compiler die Strings zusammenlegen darf, wenn es möglich ist. Er 
muss er muss aber nicht dokumentieren, ob oder wann er es macht. Wenn er 
es dokumentieren müsste, wäre es implementation defined. Undefined wird 
es, weil Pointer auf unterschiedliche Objekte verglichen werden, wenn er 
sie nicht zusammen legt.
Da du dir aber nicht sicher sein kannst welches Verhalten gerade 
zutrifft, ist es effektiv immer undefined.

Walter T. schrieb:
> mh schrieb:
>> Wenn der Compiler/Linker das
>> nicht macht, ist das Verhalten undefined, weil die beiden Pointer nicht
>> in das selbe Objekt (Array-of-char) zeigen.
> Ich kenne keine Regel, die den Vergleich beliebiger Zeiger auf
> unterschiedliche Arrays verbietet.

1

6.5.8 Relational operators

2

...

3

5) When two pointers are compared, the result depends on the relative locations in the address space

4

of the objects pointed to. If two pointers to object types both point to the same object, or both point

5

one past the last element of the same array object, they compare equal. If the objects pointed to are

6

members of the same aggregate object, pointers to structure members declared later compare greater

7

than pointers to members declared earlier in the structure, and pointers to array elements with larger

8

subscript values compare greater than pointers to elements of the same array with lower subscript

9

values. All pointers to members of the same union object compare equal. If the expression P points

10

to an element of an array object and the expression Q points to the last element of the same array

11

object, the pointer expression Q+1 compares greater than P. In all other cases, the behavior is undefined.

(prx) A. K. schrieb:
> Der C Standard kennt eine. Ein Vergleich zwischen Pointern auf
> verschiedene Arrays ist undefiniert. 6.5.8.5 ... "In all other cases,
> the behavior is undefined."

Wirklich? Pointergleichheit ist undefiniert? Oder nur kleiner/grösser?

LG, Sebastian

Walter T. schrieb:
> Ich kenne keine Regel, die diese Zeile verbietet.

Die Zeile ist nicht verboten. Aber sie enthält einige Konstrukte, die 
vielleicht anders sind als Du erwartest und die deshalb vielleicht 
andere Ergebnisse liefern als Du erwartest.

Darum die Frage, was Du erwartest.

Dass verschiedene Dinge rauskommen, liegt daran, dass der Compiler frei 
ist, das zu implementieren, wie er will.

Also ganz ehrlich, verstehst Du, wann genau true rauskommt und wann 
genau nicht?

Sebastian schrieb:
> Wirklich? Pointergleichheit ist undefiniert? Oder nur kleiner/grösser?

hier letzteres

(prx) A. K. schrieb:
> 6.5.8.5 ... "In all other cases, the behavior is undefined."

Das gilt für relationale Operatoren. Pointergleichheit wird in 6.5.9, 
inbesonders 6.5.9.6 spezifiziert. Zwei Pointer auf unterschiedliche 
Speicherbereiche sind ungleich, nicht undefiniert.

LG, Sebastian

Walter T. schrieb:
> Ich habe die letzte Zeile tatsächlich so gelesen, dass sie sich auf den
> Vergleich P == Q+1 bezieht.

Da geht es nur darum, dass man quasi das es quasi genau ein Element 
gibt, dass sicher größer als das letzte Element ist.

Hat hier aber keine Bedeutung.

Walter T. schrieb:
> Und die Frage noch zu klären: Ich erwartete hier, etwas Neues über die
> Arbeitsweise des Optimierers zu lernen.

In welcher Hinsicht?

Walter T. schrieb:
> Das erzeugt zwei Fragen:
>  a) Warum spart sich der Compiler das Schachteln der Zeichenketten in
> -O3? Ich kann durch das Schachteln keine Strafe auf die Geschwindigkeit
> erkennen.
Wozu? Die Strings fallen doch weg, er braucht sie nicht anlegen. Der 
restliche Code kann sie ja eh nicht "fassen".
>  b) Warum kann der Compiler den konstanten Ausdruck auf der rechten
> Seite nicht auswerten und wegoptimieren? Zumindest bei -Os hat er doch
> erkannt, dass die Differenz immer 4 ist?
Ist der erstellte Code in beiden gleich? Ggf. weil der Linker ja erst 
die Adressen liefert ;-)

Walter T. schrieb:
> Aber ich bin jetzt etwas irritiert:
> int a, b, *ap, *bp;
> ap = &a, bp = &b;
> int c = *ap == *bp;
> Definiert oder nicht definiert?
>
> Wenn ich mir den Absatz noch einmal in Ruhe durchlesen, würde ich
> ersteres sagen. Und c ist immer 0.
Definiert, klar. Warum nicht. Aber warum 0? was in a oder b steht ist 
doch völlig unbekannt. Die können gleich sein, müssen aber nicht.

Walter T. schrieb:
> Oben: Tippfehler. Gemeint ist natürlichint a, b, *ap, *bp;
> ap = &a, bp = &b;
> int c = ap == bp;

a und b sind doch in jedem Fall unterschiedliche Adressen. Also ja, 0, 
ungleich.

Beim String-Beispiel ist es ja eher so, dass Du zwei "zufällige" 
Adressen hast, die je nach Laune gleich oder ungleich sein können.

Da strings auch nicht unterschiedlich sein können, wenn sie den gleichen 
Anfang haben, ist das auch kein praktisches Problem.

Entweder sind strings (die Adressen) gleich, dann ist auch der Text 
gleich. Oder sie sind es nicht, dann ist der Text beliebig. Meist 
unterschiedlich, kann aber trotzdem gleich sein.

(prx) A. K. schrieb:
> Für C könnte man auch sagen, dass das Verhalten schon deshalb
> undefiniert ist, weil der Standard es weder als klar definiert noch als
> klar undefiniert definiert. ;-)

Das gilt aber nur, wenn Du

(prx) A. K. schrieb:
> 6.5.9.3: "The == (equal to) and != (not equal to) operators are
> analogous to the relational operators except for their lower
> precedence."

auf eine Eigenschaft beziehst, die nicht zwingend mitgemeint sein muss.

Es gibt ja so ein analogon bei % und / mit negativen Zahlen bei int. 
Egal wie mans macht, am Ende muss es Konsistent sein. Und bei > bzw. < 
auch: Egal was raus kommt, am Ende muss es (bei ungleichen Pointern) > 
oder < sein, um ein == zu erkennen. Und das ist so offensichtlich, dass 
es keiner expliziten Erklärung bedarf, die Hälfte aller 
Pointer-Vergleiche wäre sonst sinnlos.

A. S. schrieb:
> Definiert, klar. Warum nicht.

`a` und `b` enthalten indeterminate values, dürfen also eine /trap 
representation/ enthalten, der Zugriff darauf wäre undefined behavior.

A. S. schrieb:
> Egal was raus kommt, am Ende muss es (bei ungleichen Pointern) > oder <
> sein

Ja, aber welches von beiden kann undefined sein. Und bei zwei Zeigern 
auf unterschiedliche Variablen ist eben Ungleichheit garantiert, aber 
nicht welcher Zeiger der Grössere ist.

Die Operatoren == und != sind eben nicht relational operators nach 6.5.8 
(das sind <, >, <= und >=) sondern equality operators nach 6.5.9.

LG, Sebastian

Oliver S. schrieb:
> Der Abschnitt behandelt ausdrücklich den Vergleich von zwei Pointern,

Vergleich mit relational operators. Der Abschnitt behandelt nicht ==.

LG, Sebastian

Jörg W. schrieb:
> Ist aber für das Beispiel egal, da nur deren Adressen via & ermittelt
> werden. Die Adressen haben (nach dem Linken) einen wohl definierten
> Wert. Auf die Inhalte wird nicht zugegriffen.

Zitierter Beitrag bezieht sich noch auf das Beispiel vor der Korrektur.

Jemand schrieb:
> `a` und `b` enthalten indeterminate values, dürfen also eine /trap
> representation/ enthalten, der Zugriff darauf wäre undefined behavior.

Ich kenne mich da nicht aus. Ich hätte gedacht, es wäre bei int (@C11) 
ein "unspecified value".

1

3.19.2 indeterminate value

2

either an unspecified value or a trap representation

3

3.19.3 unspecified value

4

valid value of the relevant type where this International Standard imposes no

5

requirements on which value is chosen in any instance

6

2 NOTE An unspecified value cannot be a trap representation.

7

3.19.4 trap representation

8

an object representation that need not represent a value of the object type

A. S. schrieb:
> Ich kenne mich da nicht aus. Ich hätte gedacht, es wäre bei int (@C11)
> ein "unspecified value".

In 6.7.9 Initialization:

1

10 If an object that has automatic storage duration is not initialized explicitly, its value is

2

indeterminate. [...]

(prx) A. K. schrieb:

> Der C Standard kennt eine. Ein Vergleich zwischen Pointern auf
> verschiedene Arrays ist undefiniert. 6.5.8.5 ... "In all other cases,
> the behavior is undefined."

Wenn der zweite String nicht reingefaltet wird UND direkt nach dem 
ersten String liegt, wäre der zweite Pointer aus Sicht des ersten 
Strings so ein "q+1".

Wenn der Compiler nicht reinfaltet, kann er zur Compile-Zeit nicht 
wissen, wo die Adressen liegen werden, kann also nicht mit Sicherheit 
sagen, ob es noch q+1 sein wird oder nicht. Er darf aber q+1 annehmen, 
weil das Gegenteil undefined behaviour wäre, so daß er für den letzteren 
Fall keinen Code generieren muß.

(prx) A. K. schrieb:
> Mit dem Loch meinte ich die klare Festlegung im Standard, ob Vergleiche
> auf Identität von Pointern auf verschiedene Objekte zulässig sind.

Gratuliere! Das erfordert schon eine große Menge an echter 
Abgezogenheit, wenn im Standard steht
[code]
Two pointers compare equal if ...  both are pointers to the same object 
...
[/code
dann noch zu denken, wenn das nicht der Fall ist, wäre nicht der 
Vergleich false, sondern das Verhalten undefiniert.
Echt, Gratuliere!

Walter T. schrieb:
>> Meiner Meinung nach ist die Codezeile sinnloser Bullshit den
>> keine Regel von C beschreibt.

> Ich kenne keine Regel, die diese Zeile verbietet.

Dass stimmt.

Doch die C Spezifikation ist wie Datenblätter von Mikrochips. Wenn bei 
einem IC z.B. nicht festgelegt ist, wie vie mA die ESD Schutzdioden 
vertragen, dann sollte man sie gar nicht absichtlich belasten. Denn das 
kann heute 20mA sein und in der nächsten Charge nur 2mA.

Dein eigentliches Problem ist, dass es hier eine Lücke in der 
Spezifikation gibt. Du willst eine lückenlose Spezifikation. So ist C 
aber nicht und so wird es nie werden. Wenn dir das wirklich wichtig ist, 
musst du eine andere Programmiersprache wählen.

Bei Java hat man sich bewusst um eine weitgehend Lückenlose 
Spezifikation bemüht, damit Programme auf jeder Maschine gleich laufen 
(funktioniert in der Praxis leider nicht, aber zumindest hat man es 
versucht).

Bei C hat man bewusst viele Details nicht festgelegt, damit die 
Umsetzung auf allen damals relevanten Maschinen problemlos möglich ist. 
Die Konsequenz ist: Verlasse dich nie darauf, dass eine 
nicht-spezifizierte Eigenschaft woanders oder in Zukunft ebenso ist.

Jemand schrieb:
> In 6.7.9 Initialization: [..] indeterminate.

Ja, indeterminate ist klar. Du hast daraus gefolgert:

Jemand schrieb:
> dürfen also eine trap representation enthalten,

und ich frage, ob es nach 3.19.2 ff (@C11) nicht "unspecified value" 
ist.
A. S. schrieb:
> 3.19.2 indeterminate value
> either an unspecified value or a trap representation

Dann wäre es kein U.B. und das Ergebnis zwar zufällig aber ansonsten 
unkritisch.

Stefan ⛄ F. schrieb:
> Dein eigentliches Problem ist, dass es hier eine Lücke in der
> Spezifikation gibt.

Wieso Lücke? Der Original-Code ist normaler, perfekter C-Code. Dass das 
Ergebnis zufällig ist, hat nichts mit Spezifikation zu tun. Es ist 
genauso zufällig, wie die Adresse einer Funktion oder eines ints. Wenn 
ich die in ein uint8 caste und auf > 100 teste, dann kann sich das 
Ergebnis auch mit der Optimierungsstufe ändern.

Klaus W. schrieb:
> Schon im K&R (2. Aufl., dt, S. 99 5.4 Adreß-Arithmetik) steht:
> ... Wenn p und q auf Elemente im gleichen Vektor zeigen, dann
> funktionieren Vergleiche wie ==, !=, <, >= usw.
> ...
> Der Ablauf ist jedoch undefiniert bei Arithmetik oder Vergleichen
> zwischen Zeigern, die nicht auf Elemente des gleichen Vektors verweisen.
> (Es gibt eine Ausnahme: die Adresse des ersten Elements nach dem Ende
> eines Vektors kann für Zeigerarithmetik verwendet werden.
> ...
>
> Ok, auch K&R sind nicht immer perfekt. Aber als Richtschnur kann man das
> schon mal nehmen.

Kann man offenbar nicht. Eine Funktion

1

int f(int* p, int* q) { return p == q; }

ist immer wohldefiniert. Wenn ein Programm mit dieser Funktion spinnt, 
liegt der Fehler nicht in f.