Package home | Report new bug | New search | Development Roadmap Status: Open | Feedback | All | Closed Since Version 0.14.0

Bug #772 Wrong type assignment soap->php
Submitted: 2004-02-16 15:14 UTC
From: dirk dot oschlies at de dot bosch dot com Assigned: yunosh
Status: No Feedback Package: SOAP
PHP Version: Irrelevant OS: Irrelevant
Roadmaps: (Not assigned)    
Subscription  
Comments Add Comment Add patch


Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know! Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
MUST BE VALID
Solve the problem : 10 + 30 = ?

 
 [2004-02-16 15:14 UTC] dirk dot oschlies at de dot bosch dot com
Description: ------------ In the Base.php file is a look-up table which says in what data-type a soap value should be casted in php. At least one of this assingments is wrong. The data-type long is cast to integer. But the integer value is not capeable of such huge values. Instead the value should be cast to string, which can be handled by the bcmath library in full precesion and length. I guess the same problem will be with some unsigned integer values (positive and negative) because php does not know an unsigned integer type. The following types should be checked: nonPositiveInteger, negativeInteger, nonNegativeInteger, unsignedLong, positiveInteger, unsignedInt And another bug: byte is cast to string, but is a decimal type. So it should be cast to integer. see for details of the data types: http://www.w3c.org/TR/xmlschema-2/ I hope this helps... Regards Dirk Oschlies

Comments

 [2004-02-18 11:39 UTC] dirk dot oschlies at de dot bosch dot com
I checked all datatypes assignments another time and compared the php and xml types. The xml types are descriped here: http://www.w3.org/TR/xmlschema-2/ especialy take a look at the picture you find here: http://www.w3.org/TR/xmlschema-2/#built-in-datatypes There are even some more types which have to be corrected. This is the part were I found the first (wrong) assignment: 0.8RC3: echoLong... request: 9223372036854775807 repsonse: 2147483647 failure! Corrected: echoLong... request: 9223372036854775807 repsonse: 9223372036854775807 ok Here comes a diff file with all corrections to be made in base.php of 0.8RC3. I added comments on some datatypes to make my decission clear. base.php.diff 249,258c249,258 < 'decimal' => 'string', // decimal is a type with arbitrary precision < 'duration' => 'string', // example value 'P1Y2M3DT10H30M' < 'dateTime' => 'string', // example value '1999-05-31T13:20:00-05:00' < 'time' => 'string', // left truncated dateTime (timezone allowed) < 'date' => 'string', // right truncated dateTime (timezone allowed) < 'gYearMonth' => 'string', // right truncated dateTime (timezone allowed), example value '1999-05' < 'gYear' => 'string', // right truncated dateTime (timezone allowed) < 'gMonthDay' => 'string', // left truncated date (timezone allowed) < 'gDay' => 'string', // left truncated date (timezone allowed) < 'gMonth' => 'string', // left and right truncated date (timezone allowed) --- > 'decimal' => FLOAT, > 'duration' => 'integer', > 'dateTime' => 'string', > 'time' => 'string', > 'date' => 'string', > 'gYearMonth' => 'integer', > 'gYear' => 'integer', > 'gMonthDay' => 'integer', > 'gDay' => 'integer', > 'gMonth' => 'integer', 274,286c274,286 < 'integer' => 'string', // no length is specified, parent type of long < 'nonPositiveInteger' => 'string', // no length is specified < 'negativeInteger' => 'string', // no length is specified < 'long' => 'string', // maxInclusive 9223372036854775807, minInclusive -9223372036854775808 < 'int' => 'integer', // maxInclusive 2147483647, minInclusive -2147483648 < 'short' => 'integer', // maxInclusive 32767, minInclusive -32768 < 'byte' => 'integer', // maxInclusive 127, minInclusive -128 < 'nonNegativeInteger' => 'string', // no length is specified, parent type of unsignedLong < 'unsignedLong' => 'string', // maxInclusive 18446744073709551615 < 'unsignedInt' => 'string', // maxInclusive 4294967295 < 'unsignedShort' => 'integer', // maxInclusive 65535 < 'unsignedByte' => 'integer', // maxInclusive 255 < 'positiveInteger' => 'string', // no length is specified --- > 'integer' => 'integer', > 'nonPositiveInteger' => 'integer', > 'negativeInteger' => 'integer', > 'long' => 'integer', > 'int' => 'integer', > 'short' => 'integer', > 'byte' => 'string', > 'nonNegativeInteger' => 'integer', > 'unsignedLong' => 'integer', > 'unsignedInt' => 'integer', > 'unsignedShort' => 'integer', > 'unsignedByte' => 'integer', > 'positiveInteger' => 'integer',
 [2004-04-03 09:34 UTC] arnaud
Hi, Can you provide a unified diff (diff -u) ? Thanks.
 [2004-04-03 09:40 UTC] arnaud
The best would be to provide a unified diff against latest cvs version (cvs diff -u Base.php) and put the patch online somewhere or send it to me as an attachment. Thanks.
 [2005-02-10 00:51 UTC] yunosh
No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you.
 [2005-07-15 10:01 UTC] nkahn at cmd dot lu
The problem is still present in current version (0.9.1) of SOAP package. Some types are not mapped correctly in file 'Base.php'. For example I should have received the ID '4610000000811' but I received the ID '2147483647' instead which is the maximal value of a signed integer. I have implemented Dirk patch and everything seems to work properly. Could you give a feedback on that problem and update the CVS if you could ? Thanks Nicolas Kahn