On 07.05.2014 21:29, Rowan Collins wrote:
Andrea Faulds wrote (on 07/05/2014):
On 7 May 2014, at 19:11, Rowan Collins <email@example.com
Ooh, that reminds me of something I've been meaning to file a bug
for, and maybe even attempt a patch, if I can understand where it
comes from: the message shown *to the user* when an internal function
is passed an invalid value uses "double" and "long" instead of
"float" and "int".
…that’s probably from zend_parse_parameters, no?
Following the code by eye, I think the patch would just be the attached
- I haven't actually got a build environment to test it in, though, I'm
just killing time while a colleague tests something.
Using "integer" rather than "int" matches zend_get_type_by_const, which
is is used for the "given" part of the message; floats are "double" in
that function, which is documented behaviour of gettype
gettype should be the only part where the PHP type is named "double" and
this is documented as follows: ""double" (for historical reasons
"double" is returned in case of a float, and not simply "float")".
For fun: Behind this very old BC safe change "gettype()" contains a
warning to not use this function for type checks but to use the
-> I also would prefer to change "double" to "float" within the function
"gettype" or ad a new function like "typeof()" and deprecate the old one
for BC reasons ... but this is another request.
* is_double() is an alias of is_float()
* doubleval() is an alias of floatval()
* on Type-Casting it's documented as:
"(float), (double), (real) - cast to float"
The only downside I can think of of this change is that since error
messages have no machine-readable form, people may be relying on
matching the original text. Everything's a breaking change to someone I