fireweasel

Uiuiui, das ist mir jetzt peinlich. Da hatte ich mal wieder die ganzen Bytes gezählt, statt der halben. Natürlich war "%x016" gemeint. "Z_OBJ_HANDLE_PP(obj)" wäre mir aber ohnehin lieber ...

__________________
Wir schreiben schließlich Code und malen keine ASCII-Bilder.

Mister Ad

mepeisen

Trotzdem hättest du mit dem Vertrag bei 64bit-Systemen ein Problem. Der Vertrag sagt: Der Hash muss EINDEUTIG sein. Ein reines %016x auf die Adresse im RAM ist nicht garantiert eindeutig. Deswegen diese "Magic". Was die Makros da tun, müsste man mal schauen, aber es scheint dadurch generell eindeutig zu werden.

__________________
www.php-maven.org PHP und Maven vereint: Build/Deploy/Produktion/Konfiguration, Projekt Management, CI, PHPUnit, zahlreiche Frameworks
Twitter @ https://twitter.com/#!/mepeisen und Facebook @ http://t.co/DZnKSUih

fireweasel

Wieso sollte die Adresse nicht eindeutig sein? Können sich zwei unterschiedliche PHP-Objekte eine Adresse teilen?
Möglicherweise war meine improvisierte sprintf-Anwendung da unpassend, ich wollte die Adresse und nicht die Daten, die sich dort befinden.

Ich würde sowieso die Objekt-ID, also Z_OBJ_HANDLE_PP() bevorzugen.

__________________
Wir schreiben schließlich Code und malen keine ASCII-Bilder.

mepeisen

Die Adresse ist selbst eindeutig. Aber nicht als unsigned int darstellbar. Das war sie noch nie. Dazu müsste ich nun erklären, wie Adressierung in der Intel-Architektur funktioniert. Glaube mir einfach mal, dass auf 32Bit-Systemen die Adresse generell über 48Bit dargestellt wird. Auf 64 Bit-Systemen müssten das ebenfalls entweder 80 Bit oder mehr sein (Falls du nachschlagen willst: Zauberwort Selektor oder Far-Pointer vs. Near-Pointer). Theoretisch kann die Adresse mit 64Bit eindeutig sein (Programme arbeiten in der Regel nur mit einem Selektor für Code und einem zweiten für Heap), das garantieren, würde ich nicht wollen. Die eindeutige Adresse ist somit niemals so exakt über printf darstellbar, wenn man sich unabhängig von physiklaischer Adressierung des Speichers machen will. Es gibt Prozessorsysteme, da ist es noch komplizierter.
Genau aus diesem Grund, um die Abhängigkeit zur physikalischen Ausrichtung von Speicherbereichen zu vermeiden, sollte man niemals einfach so wortlos davon ausgehen, dass eine hexadezimale Ausgabe von Adressen eindeutig ist. Um Beispielsweise zu Debugging-Zwecken mal nachvollziehen was passiert, ist das OK. Mehr nicht. Es kann je nach Compiler bereits ein unterschiedliches Segment für Heap und Stack geben und schon hast du Probleme Adressen eins zu eins zu übersetzen. Dann kann die 64-Bit-Adresse 0x0001000200030004 unterschiedliche Speicherbereiche meinen, je nachdem ob sie mit Stack-Selektor oder Heap-Selektor geladen wird.

__________________
www.php-maven.org PHP und Maven vereint: Build/Deploy/Produktion/Konfiguration, Projekt Management, CI, PHPUnit, zahlreiche Frameworks
Twitter @ https://twitter.com/#!/mepeisen und Facebook @ http://t.co/DZnKSUih

fireweasel

Ojeh, wir kommen nicht nur vom Thema ab (tun wir?), es wird auch immer komplizierter. Lassen wir mal die Ausgabe und Umwandlung einer "Viel"-Bit-Integer-Zahl per sprintf() ausgeblendet oder nehmen einfach an, es könnte so funktionieren, wie mein unkompliziert gewebtes Gemüt sich das so vorstellt(e) ...

Muss ich ja wohl, da mir größtenteils einfach das Verständnis für die verquere x86-Logik fehlt. Mit 68k und PPC kam|komme ich besser zurecht.

Okay, dann machen wir das ganze halt ein paar Bits breiter. Das erschien mir aber (anfangs) immer noch vernünftiger, als mit Zufallsfunktionen (... mt_rand() ...) eine ID auszuwürfeln.

Zwischenruf: Wurde der umständliche Far-Near-Unfug nicht irgendwann in den Neunzigern abgeschafft? Zauberwort: Flat-Memory-Model?

Und das googeln nach deinen Zauberwörtern bringt für meinen Geschmack etwas zu viel archäologisch interessanten Kram hervor (Pattern wie "286" und "16 Bit" bspw.).
[1]

Stimmt, zu eng gedacht. Physikalische Adressen sind nun mal keine logischen ... Address-Aliasing und der ganze Kram, wenn man segmentierte Speichermodelle benutzt.

Sollte man nicht trotzdem annehmen können, dass PHP-Objekte (wie alle diese Zend-Val-Dinger) immer auf dem Heap alloziert werden? ...

Nein, jetzt werden's mir zu viele Annahmen, ... Z_OBJ_HANDLE_PP() und gut ist's.

--

[1] Falls hier noch wer mitliest, ein paar (für mich) interessante Google-Suchergebnisse, die irgendwie zum Thema (Speicher, Adressen usw.) passen:

http://www.ualberta.ca/CNS/RESEARCH/...sters/mem.html

http://stackoverflow.com/questions/4...t-memory-limit

http://blogs.technet.com/b/markrussi...1/3092070.aspx

__________________
Wir schreiben schließlich Code und malen keine ASCII-Bilder.

mepeisen

Mag sein, dass ich mit Far-Pointer und Near-Pointer die falschen Begrifflichkeiten verwendet habe. Das sind in der Tat Schlagworte aus der 16Bit Architektur. Das Grundprinzip dahinter wurde aber in x86 nie abgeschafft. Es gibt nach wie vor eine Art Segmentierung und auch die Selektoren. Aber ja, wir driften weit vom Thema ab

__________________
www.php-maven.org PHP und Maven vereint: Build/Deploy/Produktion/Konfiguration, Projekt Management, CI, PHPUnit, zahlreiche Frameworks
Twitter @ https://twitter.com/#!/mepeisen und Facebook @ http://t.co/DZnKSUih

fireweasel

Zur Einführung in die Thematik reicht(e) das aus. Ich kann schließlich selbst weitergoogeln und -lesen.

Aber niemand soll mehr behaupten, hier würde man auf naive Fragen keine ausführlichen Antworten bekommen.

__________________
Wir schreiben schließlich Code und malen keine ASCII-Bilder.