I: [phpxmlrpc-devel] is this list working?

[Gaetano G. <giu...@se...>]

> >=20
> > so i'm wondering if those mail successfull arrived to list.
> >=20
>=20
> yes, it deed
>=20
> > had anybody read mail about float/double numbers encoding?
> >=20
>=20
> I am in no way a major developer of the lib, here's my take anyway:
>=20
> > there is a problem with very big(or very small) float=20
> > numbers. php automagically converts it to scientific number
> > for example
> > 	1300000000000000000000 to 1.3e21
> >=20
> > xmlrpc server accepts it as valid double value, but xmlrpc=20
> > client "converts" it to ERROR_NON_NUMERIC_FOUND, because it=20
> > doesn't match to "^[0-9\+\-\.]+$" regexp.
> > 	i see 2 solutions:
> > 1) let php server accept scientific format, and replace=20
> > regexp based check by is_float(). but xmlrpc specification=20
> > is unclear for me, and i'm not sure if it allow scientific=20
> > format of double number.
> >=20
>=20
> The spec is deceptively simple in many places, here's the=20
> concerning paragraph:
>=20
>   # What is the legal syntax (and range) for floating point=20
> values (doubles)? How is the exponent represented? How to=20
> deal with whitespace?  Can infinity and "not a number" be represented?
>=20
>   There is no representation for infinity or negative=20
> infinity or "not a number". At this time, only decimal point=20
> notation is allowed, a plus or a minus, followed by any=20
> number of numeric characters, followed by a period and any=20
> number of numeric characters. Whitespace is not allowed. The=20
> range of allowable values is implementation-dependent, is not=20
> specified.
>=20
> As far as my understanding goes, NO scientific notation allowed.
> In fact the regexp above looks a bit too wide: to stick=20
> closely to the spec ^[\+\-][0-9]*\.[0-9]*$ could be more appropriate.
> btw: this excludes values as "1" or "1.0" but allows for=20
> "+.5", "+1." or even "+."
> If we take 'any number' in the spec to mean 1 or more then=20
> the regexp would of course be ^[\+\-][0-9]+\.[0-9]+$
>=20
> As a sidenote, the lib uses in fact "^\-?[0123456789 \t\.]+$"=20
> regexp to validate both INT and DOUBLE types.
> THIS IS QUITE WRONG, since the spec paragraph concerning int=20
> values reads:
>=20
>   # What is the legal syntax (and range) for integers? How to=20
> deal with leading zeros? Is a leading plus sign allowed? How=20
> to deal with whitespace?
>=20
>   An integer is a 32-bit signed number. You can include a=20
> plus or minus at the beginning of a string of numeric=20
> characters. Leading zeros are collapsed. Whitespace is not=20
> permitted. Just numeric characters preceeded by a plus or minus.
>=20
> The correct regexp for integers is then: [\+\-]?0*[0-9]{1,10}=20
> or maybe simply [\+\-]?[0-9]{1,10}
>=20
> Of course, there is always the option to let the library be=20
> forgiving and accept a wider range of values than stated in=20
> the the spec (while emitting conforming values only).
> But using a bad validation (as the lib does now) is IMHO=20
> scarcely better than doing no validation at all...
>=20
> > 2) convert every big or small double to normal format using=20
> > sprintf and proper precision modifier. but it can generate=20
> > amount of unneeded data (1.3e55 takes 6 bytes, 13000....0000=20
> > takes 56 bytes).
> >=20
>=20
> A very large amount of data indeed, but it is the only way to go!
>=20
> Bye, Gaetano
>=20