Hallo Zusammen,
mir ist gerade ein Bug in IPS_RunScriptEx aufgefallen (möglicherweise Systemweit). Wenn ich ein Array mit Zahlen außerhalb des Bereiches von 4 Byte Integern übergeben möchte, werden diese falsch weitergegeben. Zahlen im Bereich von -2147483647 bis 2147483647 funktionieren einwandfrei. Dieses Problem ist erst nach dem letzten Update 5.0 aufgetaucht.
Vielen Dank
Kann das jemand bestätigen, oder das Symcon Team was dazu sagen?
Aufgefallen ist mir das Problem da das Telegeram Modul nicht mit Super Gruppen kommunizieren kann, da die Gruppen ID größer als die 4 Byte ist.
Gesendet von iPhone mit Tapatalk
Das ist die PHP Grenze.
PHP: Integers - Manual
Und da es IPS auch für den Pi gibt…
Größere Zahlen dann nur unter Ubuntu und Windows x64 mit IPS (PHP7).
Michael
PS: MacOs keine Ahnung 
Naja IPS in der neuesten Version 5.0 läuft auf einem Windows 10 x64 System.
Vor dem Update auf 5.0 ging auch alles ohne Probleme. Und in der Doku steht:
ParameterKey (string) => Value (variant)
Gesendet von iPhone mit Tapatalk
Ja und was soll nun der Verweis auf die Doku? Variant kann ja alles sein.
Und da es eh nie durch PHP für alle Systeme eine Unterstützung für große Zahlen gibt, ist die 32 Bit Grenze schon logisch.
Vor IPS 5 also mit PHP 5.x war die 32 Bit Grenze unter Windows auf jeden Fall schon vorhanden. Die ist unter Windows erst mit PHP 7 gefallen.
Michael
Hallo,
vielen Dank für die schnelle Antwort. Ich glaube aber wir reden aneinander vorbei.
Bitte schau DIr doch mal kurz dieses Beispielscript an. Es zeigt sehr genau was mein Problem ist.
<?
$long = 2147483647 + 1;
echo $long; // 2147483648
IPS_RunScriptEx(53589 /* script siehe unten */, [ "LONG" => $long ]);
?>
Im zweiten Script (53589) steht:
<?
echo $_IPS['LONG']; // -2147483648
?>
Hier sieht man, dass IPS_RunScriptEx den Parameter „LONG“ verfälscht.
Das hat genau so früher wunderbar funktioniert. Da das „echo $long“ im ersten Script funktioniert und erst nach der Übergabe nicht mehr korrekt ist, ist das in meinen Augen ein Bug von IPS_RunScriptEx und kann nicht mit der PHP Version oder dem Betriebssystem in Verbindung stehen. Siehst du das anders?
Gruß
Tasmanie
echo konvertiert deine Zahl zu einen String um es darzustellen.
wenn du echo (int)$long im ersten Script einfügst, kommt auch schon -2147483648 raus :rolleyes:
Warum PHP teilweise mit größeren Zahlen umgehen kann, siehst du wenn du var_dump nutzt.
PHP konvertiert es dann zu einem Float.
Beispiel:
<?
$long = 2147483647 + 1;
echo $long.PHP_EOL; // String 2147483648
echo (int)$long.PHP_EOL; // int -2147483648
var_dump($long); // float 2147483648
IPS_RunScriptEx(10048 /* script siehe unten */, [ "LONG" => $long ]);
IPS_RunScriptEx(10048 /* script siehe unten */, [ "LONG" => (int)$long ]);
IPS_RunScriptEx(10048 /* script siehe unten */, [ "LONG" => (float)$long ]);
<?
var_dump($_IPS['LONG']); // var_dump um zu prüfen ob der Variablentyp korrekt ist
Ausgabe IPS 4.4 (PHP 5.X):
2147483648
-2147483648
float(2147483648)
15.05.2018 20:03:28 | ScriptEngine | Ergebnis für Skript 10048
float(2147483648)
15.05.2018 20:03:28 | ScriptEngine | Ergebnis für Skript 10048
int(-2147483648)
15.05.2018 20:03:28 | ScriptEngine | Ergebnis für Skript 10048
float(2147483648)
Ausgabe IPS 5.0 (PHP 7.2):
2147483648
2147483648
int(2147483648)
15.05.2018 20:07:16 | ScriptEngine | Ergebnis für Skript 10048
int(-2147483648)
15.05.2018 20:07:16 | ScriptEngine | Ergebnis für Skript 10048
int(-2147483648)
15.05.2018 20:11:18 | ScriptEngine | Ergebnis für Skript 10048
float(2147483648)
Somit halten wir fest.
PHP 5.6 hat getrickst und einfach einen Float aus den Wert gemacht.
IPS hat es auch als Float verarbeitet. Somit waren größere Zahlen möglich.
PHP 7.2 x64 kann mit größeren integern umgehen und gibt es so als integer an IPS weiter.
IPS arbeitet intern mit 32Bit, somit wurde aus dem Int (korrekt) ein -2147483648.
Um das gewünschte Verhalten der Konvertierung zu einen Float zu bekommen (wie bei PHP 5.X) , einfach einen cast (float) bei der Übergabe der Parameter anwenden.
Nur weil PHP 5.X getrickst hat, und du es ausgenutzt hast; kann Symcon dafür nix 
Michael
Danke für die klare Erklärung! Wirklich TOP