Erfahrungen mit neuen 64bit Mac Client - habe Probleme mit Datentypen

[pram]

Hallo zusammen, wollte mal fragen ob schon irgendwer Erfahrungen mit dem neuen 64bit Client für Mac OS gesammelt hat.

Ich habe aktuell folgendes Problem, dass scheinbar irgendwas wesentliches in den Datentypen geändert wurde.
Im Wesentlichen führen wir in einem Programmteil folgenden Code aus:

Code

Dim l as long
Dim s as String
l = anyMethod() ' diese Methode sollte 3 liefern
s = "foo."+Cstr(l)+".bar"

Die String-Variable 's' sollte nun "foo.3.bar" sein. Am neuen Mac-Client ist es aber offensichtlich "foo.4294967299.bar".
Der Wert ist dabei > 32bit lang und 4294967299(dez) = 100000003(hex) und würde niemals in einen LotusScript-Long passen
Ich hoffe mal nicht, dass die Breite des Long-Datentyps in LS geändert wurde.

Obiger Code ist nur ein sehr kleiner Ausschnitt, aus einem komplexen Programmablauf. Ich hatte leider (mangels Mac) noch nicht die Möglichkeit das Problem genauer zu untersuchen, aber evtl hat schon jemand ähnliches beobachtet.

Gruß
Roland

[Tode]

schon mal mit

Code

s = "foo."&Cstr(l)&".bar"

stattdessen probiert?

[pram]

Hallo Torsten, nein ich hatte leider noch keine Möglichkeit, näher zu forschen.

Möchte aber noch anmerken, dass der Code im 32bit Windows-Client und im 32/64 Bit Windows-Server ausreichend getestet ist und hier keine "Schweinereien" wie C-API Calls gemacht werden. Es wird lediglich mit den LS-String-Funktionen (Left/Right/Mid/Hex/CStr/...) und den üblichen Datenstrukturen (Arrays/Listen) ein NotesStream aus einem MIME-Item geparsed.
Unter Linux sind uns ebenfalls keine Probleme der Form bekannt. (Hier führen wir die Tests aber nur stichprobenartig durch.)

Gruß
Roland

[pram]

Also ich hab neue Erkenntnisse:

Unter Mac-64 bit wird der LotusScript-Long intern als 64bit geführt und künstlich auf 32bit beschränkt.
Hier wurde allerdings geschlampt, insbesondere bei der Konvertierung von Hex-Werten.


Weiterhin "funktioniert" im 64bit Client folgender Code

Code

Dim s as String
Dim l as Long
s = "9223372034707292159"
l = CLng(s)
MsgBox "s: " + s + " -> " + CStr( l )

Gibt folgenden String aus: "s: 9223372034707292159 -> 9223372034707292160"

9223372034707292159 = 0111 1111 1111 1111 1111 1111 1111 1111 0111 1111 1111 1111 1111 1111 1111 1111
9223372034707292160 = 0111 1111 1111 1111 1111 1111 1111 1111 1000 0000 0000 0000 0000 0000 0000 0000

PMR wird erstellt, es bleibt spannend

[koehlerbv]

Danke, Roland!

Bernhard

[pram]

Obige Sonderfälle kann man eigentlich vernachlässigen, da es (in unserem Anwendungsfall nicht wirklich stört)
Bei uns ist es im Wesentlichen die CLng() Funktion die uns am meisten Probleme bereitet. Mein Kollege hat heute einen PMR aufgemacht:

The long data type does not work as expected on 64bit Mac OS X Yosemite. It's possible to create values greater 4 byte and conversion function CLng() returns wrong results.                                 

E. g. when converting the text value "&H3" to long, the result is 4,294,967,299 where it should obviously be 3. The resulting number is a number with the 33rd bit set - which should not be possible for a 32 bit data type

Gruß
Roland

[pram]

APAR: https://www-304.ibm.com/support/entdocview.wss?uid=swg1LO86875
(SPR # RGAUA3RQ89)