Mailinglisten-Archive |
Hallo. > AFAIK ist nicht dokumentiert, ob das Ergebnis von round($var, 0) vom > Typ Integer oder Float ist. Ich vermute es ist immer noch Float, > d.h. > es kann erneut zu unerwarteten Ergebnissen kommen. IMO ist dokumentiert, dass der Rückgabetyp von round($var,0) vom Typ Float ist, da keine Ausnahmeregelung für null Nachkommastellen dokumentiert ist. ;-) Alles andere wäre auch in Bezug auf floor($var) und ceil($var) inkonsistent, deren Rückgabewert ebenfalls vom Typ Float ist. Eine kleine Frage hätte ich jedoch: Wenn ich alles richtig verstanden habe kann es richtig ärgerlich werden, wenn jemand - wie ich ;-) - auf die Idee kommt ganzzahlige Nutzereingaben oder Parameterübergaben, mit $zahl = floor($_POST['Eingabe']) oder $zahl = round($_GET['Parameter']) aus Vorsicht gegen SQL-Injections abzusichern. Wegen "When converting from float to integer, the number will be rounded towards zero." und der in diesem Thread besprochenen Darstellungsungenauigkeit könnte folgendes passieren: - $_GET['DatensatzID'] ist mit '12324' bzw. einer "bösen" Ziffernfolge belegt. - "UPDATE `wichtigeDaten` SET `datensatz`='$daten' WHERE `ID`=".floor($_GET['DatensatzID'])." LIMIT 1;"; ändert jedoch den Datensatz mit der ID 12323 statt 12324, weil eine interne Typenkonvertierung über String hin zu Integer stattgefunden hat, welche einfach 0.9999999999999...926 abgeschnitten hat. => H O R R O R ! => Wenn nicht jeder Input mitgeloggt wurde, ist so ein Fehler praktisch nicht reproduzierbar! Ist das so richtig oder kommt bei der Typenkonvertierung zum String die interne Darstellungsungenauigkeit nicht zum Tragen? Gruß, Thomas
php::bar PHP Wiki - Listenarchive