expertenaustausch > comp.lang.* > comp.lang.c

Thomas Koenig (14.04.2019, 00:50)
Da versuchen doch tatsächlich Leute, mal die Pointer-Semantik von
C klarzuziehen... spannend.





Mal gespannt, was daraus wird.
Helmut Schellong (14.04.2019, 11:58)
On 04/14/2019 00:50, Thomas Koenig wrote:
> Da versuchen doch tatsächlich Leute, mal die Pointer-Semantik von
> C klarzuziehen... spannend.
>
>
>
> Mal gespannt, was daraus wird.


Ob man das als "klarzuziehen" bezeichnen kann, bezweifle
ich im Moment.

Die scheinen eine Optimierung zu beabsichtigen: Pointer-Alias, etc.

"adjacent" gibt es bisher nur bei Array-Elementen.
Man darf hinter das letzte Element zeigen, jedoch nicht
zugreifen - auch kein Lesezugriff.

Deshalb:
for (end=(bp=buf)+sizeof(buf); bp<end; ++bp) { ...; }
Der End-Pointer 'end' zeigt hinter das letzte Element.
Sobald 'bp' auch dorthin zeigt, ist die Schleife fertig.

3. The BASIC IDEA
------------------
# include < stdio .h >
# include < string .h >
int y =2 , x =1;
int main() {
int * p = & x + 1;
int * q = & y ;
printf ( " Addresses : p =% p q =% p \ n " ,( void *) p ,( void *) q ) ;
if ( memcmp (& p , &q , sizeof ( p ) ) == 0) {
* p = 11; // does this have undefined behaviour ?
printf ( " x =% d y =% d * p =% d * q =% d \ n " ,x ,y ,* p ,* q ) ;
}
}

Es fällt hier auf, daß y höher im Speicher liegen soll als x.
Laut der bisherigen C-Standards dürfen keine bestimmten
Positionen von Objekten (y,x) im Speicher angenommen werden.
Auch ist *p=11; verboten.

Bisher habe ich nur ein paar Seiten .pdf gelesen...
Thomas Koenig (14.04.2019, 13:02)
Helmut Schellong <rip> schrieb:
> On 04/14/2019 00:50, Thomas Koenig wrote:
> Ob man das als "klarzuziehen" bezeichnen kann, bezweifle
> ich im Moment.
> Die scheinen eine Optimierung zu beabsichtigen: Pointer-Alias, etc.


Das ist ja genau das, was schon passiert, aber unterschiedliche
Compiler legen da unterschiedliches Verhalten an den Tag.

[..]
> }
> }
> Es fällt hier auf, daß y höher im Speicher liegen soll als x.


Problem ist eher, dass dieses Programm (nach der Meinung der
Leute in WG14, und die sollten es eigentlich wissen) nicht
klar undefiniert ist.

Eine weniger präzise, aber dafür einfacher zu verstehende
Zusammenfassung findet sich unter

Rainer Weikusat (14.04.2019, 16:05)
Thomas Koenig <tkoenig> writes:
> Da versuchen doch tatsächlich Leute, mal die Pointer-Semantik von
> C klarzuziehen... spannend.


s/klar/krumm/

ist auch weder neu noch spannend. Jeder Mensch, der dieser Ansicht ist,
weiss bereits seit 197x das die Zeigersemantik von C "jedenfalls
vollkommen falsch ist" und so lange sie nicht gestorben sind, versuchen
sie das jeder Generation aufs neue aufzuschwaetzen.
Thomas Koenig (14.04.2019, 16:45)
Rainer Weikusat <rweikusat> schrieb:
> Thomas Koenig <tkoenig> writes:
> s/klar/krumm/
> ist auch weder neu noch spannend. Jeder Mensch, der dieser Ansicht ist,
> weiss bereits seit 197x das die Zeigersemantik von C "jedenfalls
> vollkommen falsch ist" und so lange sie nicht gestorben sind, versuchen
> sie das jeder Generation aufs neue aufzuschwaetzen.


Meinst du jetzt mich oder WG14? :-)
Bonita Montero (14.04.2019, 16:54)
> 3. The BASIC IDEA
[..]
>      printf ( " x =% d y =% d * p =% d * q =% d \ n " ,x ,y ,* p ,* q ) ;
>    }
> }


Also ein realistischeres Beispiel hätte man schon nehmen können.
Etwa eine Struktur mit zwei "aneinanderligenden" Elementen. Dass
zwei globale Variablen im Adressraum nebeneinanderliegen, darauf
verlässt sich sicher kaum einer.
Thomas Koenig (14.04.2019, 18:58)
Bonita Montero <Bonita.Montero> schrieb:
> Also ein realistischeres Beispiel hätte man schon nehmen können.
> Etwa eine Struktur mit zwei "aneinanderligenden" Elementen. Dass
> zwei globale Variablen im Adressraum nebeneinanderliegen, darauf
> verlässt sich sicher kaum einer.


Sollte auch keiner. Bisher ist es aber anscheinend nicht explizit
verboten (a.k.a undefined behavior), und u.a. das wollen sie jetzt
ändern.
Bonita Montero (14.04.2019, 19:01)
>> Also ein realistischeres Beispiel hätte man schon nehmen können.
>> Etwa eine Struktur mit zwei "aneinanderligenden" Elementen. Dass
>> zwei globale Variablen im Adressraum nebeneinanderliegen, darauf
>> verlässt sich sicher kaum einer.


> Sollte auch keiner. Bisher ist es aber anscheinend nicht explizit
> verboten (a.k.a undefined behavior), und u.a. das wollen sie jetzt
> ändern.


Naja, die Compiler lassen sich dazu anweisen, prinzipiell Aliasing
anzunehmen und wenn man dan entsprechende Optimierungen braucht,
dann gibt es restrict-Pointer.
Thomas Koenig (14.04.2019, 19:10)
Bonita Montero <Bonita.Montero> schrieb:
> Naja, die Compiler lassen sich dazu anweisen, prinzipiell Aliasing
> anzunehmen


Die Leute, die die Compiler schreiben und die Mitglieder von WG14
(die Gruppen überschneiden sich) sind da eher anderer Meinung,
sonst bräuchte man den ganzen Krempel nicht.

Aber vermutlich weisst du das viel besser als die, wie üblich :-)
Bonita Montero (14.04.2019, 19:19)
>> Naja, die Compiler lassen sich dazu anweisen, prinzipiell Aliasing
>> anzunehmen


> Die Leute, die die Compiler schreiben und die Mitglieder von WG14
> (die Gruppen überschneiden sich) sind da eher anderer Meinung,
> sonst bräuchte man den ganzen Krempel nicht.
> Aber vermutlich weisst du das viel besser als die, wie üblich :-)


Ja, stellst Du so polemisch hin indem Du obiges Zitat kürzt. Die
Annahme von Aliasing einzuschalten und ggf. restricted-Pointer zu
nutzen ist EINE gangbare Lösung. C drückt einem so viele Lowlevel
-Kleinigkeiten auf, dass das auch keine große Last mehr ist.
Thomas Koenig (14.04.2019, 19:28)
Bonita Montero <Bonita.Montero> schrieb:
> Ja, stellst Du so polemisch hin


OMG, ich bin ein Poleme (Polemier? Polymer?). Wie niederschmetternd
für mich.

>indem Du obiges Zitat kürzt. Die
> Annahme von Aliasing einzuschalten und ggf. restricted-Pointer zu
> nutzen ist EINE gangbare Lösung.


Dann erzähl mir doch mal bitte, welche Option das in gcc sein soll.

Und wenn das alles kein Problem ist, warum kümmert sich WG14 darum?
Bonita Montero (14.04.2019, 19:45)
> Dann erzähl mir doch mal bitte, welche Option das in gcc sein soll.

Weiß ich nicht, aber dann muss es wohl so sein, dass der gcc Aliasing im
Zweifelsfall ohnehin annimmt; muss ja wohl so sein, denn sonst würde man
mit ner Menge Code Probleme kriegen ohne entsprechende Option. Grund-
sätzlich ist das aber kein Problem, ein genelles no-aliasing zu unter-
stüzen, denn das kommt ja aufs gleiche raus als wären alle Pointer eben
als restrict markiert.
Aber ob es nun eine Option dazu gibt, die den Compiler dazu zwingt, im
Zweifelsfall Aliasing anzunehmen oder ob der das per-se tut ist ja egal
wennm man eben nicht das Gegenteil vom Compiler verlangen will. Man lan-
det bei der gleichen Lösung wie von mir vorgeschlagen wenn der Compiler
eben so vorgeht und man zusätzlich restrict-Pointer einsetzt.
Ich mein, die Nutzung solcher Pointer ist eben recht einfach und mini-
malistiasch und erübrigt eigentlich jeden weiteren Zirkus.
Thomas Koenig (14.04.2019, 20:03)
Bonita Montero <Bonita.Montero> schrieb:
>> Dann erzähl mir doch mal bitte, welche Option das in gcc sein soll.

> Weiß ich nicht,


Beweisführung durch Nichtwissen war schon immer überzeugend :-)
Du schriebst

>>> Naja, die Compiler lassen sich dazu anweisen, prinzipiell Aliasing
>>> anzunehmen


und ich würde gerne von dir wissen, wie. Ansonsten, kann ich deine
Aussage unter "haltlose Tatsachenbeschreibung" einsortieren, mit
deinem Einverständnis.

>aber dann muss es wohl so sein, dass der gcc Aliasing im
> Zweifelsfall ohnehin annimmt;


"muss es wohl so sein" ist noch viel überzeugender als Beweis
durch Nichtwissen.

> muss ja wohl so sein, denn sonst würde man
> mit ner Menge Code Probleme kriegen ohne entsprechende Option. Grund-
> sätzlich ist das aber kein Problem, ein genelles no-aliasing zu unter-
> stüzen, denn das kommt ja aufs gleiche raus als wären alle Pointer eben
> als restrict markiert.


Wenn das dein Verständnis von C ist, dann hast du noch viel
grundlegendere Probleme mit dieser Sprache, als ich sowieso schon
dachte.

> Aber ob es nun eine Option dazu gibt, die den Compiler dazu zwingt, im
> Zweifelsfall Aliasing anzunehmen oder ob der das per-se tut ist ja egal


Die Frage ist halt, genau für welche Fälle.

> wennm man eben nicht das Gegenteil vom Compiler verlangen will. Man lan-
> det bei der gleichen Lösung wie von mir vorgeschlagen wenn der Compiler
> eben so vorgeht und man zusätzlich restrict-Pointer einsetzt.
> Ich mein, die Nutzung solcher Pointer ist eben recht einfach und mini-
> malistiasch und erübrigt eigentlich jeden weiteren Zirkus.


Also, du weisst es doch besser als die Mitglieder von WG14?
Respekt, so ein tiefes und fundamentales Verständnis hätte ich
dir gar nicht zugetraut.
Bonita Montero (14.04.2019, 20:15)
>> aber dann muss es wohl so sein, dass der gcc Aliasing im
>> Zweifelsfall ohnehin annimmt;


> "muss es wohl so sein" ist noch viel überzeugender als Beweis
> durch Nichtwissen.


Es kann nicht anders sein, denn sonst würde eine Menge Code die
eben "aliast" nicht funktionieren.

>> muss ja wohl so sein, denn sonst würde man
>> mit ner Menge Code Probleme kriegen ohne entsprechende Option. Grund-
>> sätzlich ist das aber kein Problem, ein genelles no-aliasing zu unter-
>> stüzen, denn das kommt ja aufs gleiche raus als wären alle Pointer eben
>> als restrict markiert.


> Wenn das dein Verständnis von C ist, dann hast du noch viel
> grundlegendere Probleme mit dieser Sprache, als ich sowieso schon
> dachte.


Du hast _nichts_ von obigem Zitat verstanden!
Früher gab es mal bei MSVC eine Compiler-Option "assume no aliasing".
Die macht genau das was ich oben beschrieben habe. Haben die aber
rausgenommen weil das gefährlich Optimierten Code erzeugen kann.
Aber wie man sieht und wie ich oben begründe und wie Du offensichtlich
nicht verstehst ist möglich, das zu unterstützen bzw. modul-weit zu
konfigurieren, dass alle Pointer so wie restricted-Pointer behandelt
werden sollen. Jetzt verstanden?
Aber ob der Compiler explizit dazu gezwungen werden muss, im Zweifels-
falle Aliasing anzunehmen oder ob er das per-se tut kommt ja für meinen
Vorschlag auf's gleiche raus. Jetzt verstanden?

>> Aber ob es nun eine Option dazu gibt, die den Compiler dazu zwingt, im
>> Zweifelsfall Aliasing anzunehmen oder ob der das per-se tut ist ja egal


> Die Frage ist halt, genau für welche Fälle.


Ach!

> Also, du weisst es doch besser als die Mitglieder von WG14?


Ja, deren Arbeit ist an der Stelle nicht nötig. Eine Lowlevel-Sprache
wie C braucht das nicht zumal die wie gesagt bereits eine Lösung dafür
anbietet.
Thomas Koenig (14.04.2019, 20:48)
Bonita Montero <Bonita.Montero> schrieb:
> Es kann nicht anders sein, denn sonst würde eine Menge Code die
> eben "aliast" nicht funktionieren.
> Du hast _nichts_ von obigem Zitat verstanden!


Da gab es ja auch wohl nichts zu verstehen.

> Früher gab es mal bei MSVC eine Compiler-Option "assume no aliasing".


Ah, Historie.

> Die macht genau das was ich oben beschrieben habe.


Na, dann muss das ja wohl auch für jeden anderen Compiler gelten,
sehe ich sofort ein.

> Haben die aber
> rausgenommen weil das gefährlich Optimierten Code erzeugen kann.


Kein Wunder.

> Aber wie man sieht und wie ich oben begründe und wie Du offensichtlich
> nicht verstehst ist möglich, das zu unterstützen bzw. modul-weit zu
> konfigurieren,


Modul? Kenne ich in C nicht, dafür aber in Fortran und Ada
(und bald möglicherweise, horribile dictu, in C++). Sicher,
dass du die richtige Programmiersprache meinst? Über C scheinst
du im Augenblick nicht zu reden.

>dass alle Pointer so wie restricted-Pointer behandelt
> werden sollen. Jetzt verstanden?


Ja, da wollte jemand eine andere Programmiersprache als C.

> Aber ob der Compiler explizit dazu gezwungen werden muss, im Zweifels-
> falle Aliasing anzunehmen oder ob er das per-se tut kommt ja für meinen
> Vorschlag auf's gleiche raus. Jetzt verstanden?


Ich habe schon verstanden, dass du die Sprachdefinition von C für so
beliebig hältst, dass man sie mit einer Option an- oder ausschalten
kann (oder können sollte). Passt zu deiner Einstellung.

>> Also, du weisst es doch besser als die Mitglieder von WG14?


> Ja, deren Arbeit ist an der Stelle nicht nötig. Eine Lowlevel-Sprache
> wie C braucht das nicht zumal die wie gesagt bereits eine Lösung dafür
> anbietet.


Du hast das Problem, um das es in den Dokumenten geht, auch nicht
mal ansatzweise verstanden. Verwunderlich? Eher nicht.

Ähnliche Themen