| Re: bug in is_numeric [message #181381 is a reply to message #181380] |
Tue, 14 May 2013 14:54   |
Denis McMahon
Messages: 634
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On Tue, 14 May 2013 14:47:57 +0100, fred wrote:
> I can't work out if you're all a bunch of mentally deficient half wits
> or just too stupid to run a correct test.
>
> Either way its been reported I'm no longer interested.
You seem to have totally missed the points that are being made:
1) The test you ran on your system (this is the code that Sal asked you
to run) gave a correct result for the test case you specified.
Specifically it returned boolean value FALSE for an is_numeric() test of
the string value "x11.11c".
2) The code that you posted here as a specific example of failing code
was obviously not the code that is actually failing, because it was
syntatically broken php. Specifically it had a terminating ";" outside of
the braces "{}" that enclosed the print statement following the test
condition in the if clause.
At the moment, the only "evidence" for the problem is your original
assertion, which is not supported by the specific test case that Sal
asked you to execute, and which was based on the exact error that you
originally asserted.
Yes we would like to help you solve the problem, but so far, you have not
shown any evidence that the problem is any sort of bug in is_numeric. If
anything, the test case that Sal gave you proves that on your machine,
under the conditions that you specified, is_numeric is working properly.
The conclusion is that the case that's causing what you perceive to be an
error condition isn't the case that you originally or subsequently
stated, and unless you tell us what the actual code is that causes what
you perceive to be an error, there's very little we can do to help.
My suspicion is that although for some reason you think the string value
"x11.11c" is being passed to the test function is_numeric, some other
value is actually being passed.
--
Denis McMahon, denismfmcmahon(at)gmail(dot)com
|
|
|
|
| Re: bug in is_numeric [message #181385 is a reply to message #181379] |
Wed, 15 May 2013 01:43 |
SwissCheese
Messages: 17
Registered: December 2012
Karma: 0
|
Junior Member |
|
|
On 05/14/2013 09:41 AM, Richard Yates wrote:
> On Mon, 13 May 2013 15:15:06 +0100, fred <email(at)address(dot)com> wrote:
>
>> In article <kmqs3c$e3s$1(at)dont-email(dot)me>, jstucklex(at)attglobal(dot)net says...
>>> As others have shown, is_numeric() returns false in several versions of PHP.
>>>
>>
>> I have just typed in an exact copy of the test in my message of 02:58pm
>> When you have run that on an apache PHP installation of the same version
>> PHP as I listed (5.3.6) under windows7-64 bit - get back to me.
>>
>> Otherwise I'm done repeating myself.
>>
>
> <?php
> $a = 'x11.11c';
> if(is_numeric($a)) { echo 'oops - a problem'; } else { echo 'okay'; }
> ?>
>
> Prints 'okay'
>
> Windows 7 Home Premium 64 bit, PHP5.3.4, Apache2.2.17, (WAMP)
>
That's backwards... you want:
$a = 'x11.11c';
if(is_numeric($a)) { echo 'ok'; } else { echo 'not okay'; }
Sorry, hit send too quick!
--
Norman
Registered Linux user #461062
-Have you been to www.php.net yet?-
|
|
|
|
| Re: bug in is_numeric [message #181386 is a reply to message #181385] |
Wed, 15 May 2013 03:01 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 5/14/2013 9:43 PM, SwissCheese wrote:
> On 05/14/2013 09:41 AM, Richard Yates wrote:
>> On Mon, 13 May 2013 15:15:06 +0100, fred <email(at)address(dot)com> wrote:
>>
>>> In article <kmqs3c$e3s$1(at)dont-email(dot)me>, jstucklex(at)attglobal(dot)net says...
>>>> As others have shown, is_numeric() returns false in several versions
>>>> of PHP.
>>>>
>>>
>>> I have just typed in an exact copy of the test in my message of 02:58pm
>>> When you have run that on an apache PHP installation of the same version
>>> PHP as I listed (5.3.6) under windows7-64 bit - get back to me.
>>>
>>> Otherwise I'm done repeating myself.
>>>
>>
>> <?php
>> $a = 'x11.11c';
>> if(is_numeric($a)) { echo 'oops - a problem'; } else { echo 'okay'; }
>> ?>
>>
>> Prints 'okay'
>>
>> Windows 7 Home Premium 64 bit, PHP5.3.4, Apache2.2.17, (WAMP)
>>
>
> That's backwards... you want:
>
> $a = 'x11.11c';
> if(is_numeric($a)) { echo 'ok'; } else { echo 'not okay'; }
>
> Sorry, hit send too quick!
>
No, Richard had it correct. The if statement returns false, which is
'ok'. Your code would return 'not ok' - which is incorrect.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
|
|
| Re: bug in is_numeric [message #181394 is a reply to message #181386] |
Wed, 15 May 2013 09:48 |
SwissCheese
Messages: 17
Registered: December 2012
Karma: 0
|
Junior Member |
|
|
On 05/14/2013 11:01 PM, Jerry Stuckle wrote:
> On 5/14/2013 9:43 PM, SwissCheese wrote:
>> On 05/14/2013 09:41 AM, Richard Yates wrote:
>>> On Mon, 13 May 2013 15:15:06 +0100, fred <email(at)address(dot)com> wrote:
>>>
>>>> In article <kmqs3c$e3s$1(at)dont-email(dot)me>, jstucklex(at)attglobal(dot)net
>>>> says...
>>>> > As others have shown, is_numeric() returns false in several versions
>>>> > of PHP.
>>>> >
>>>>
>>>> I have just typed in an exact copy of the test in my message of 02:58pm
>>>> When you have run that on an apache PHP installation of the same
>>>> version
>>>> PHP as I listed (5.3.6) under windows7-64 bit - get back to me.
>>>>
>>>> Otherwise I'm done repeating myself.
>>>>
>>>
>>> <?php
>>> $a = 'x11.11c';
>>> if(is_numeric($a)) { echo 'oops - a problem'; } else { echo 'okay'; }
>>> ?>
>>>
>>> Prints 'okay'
>>>
>>> Windows 7 Home Premium 64 bit, PHP5.3.4, Apache2.2.17, (WAMP)
>>>
>>
>> That's backwards... you want:
>>
>> $a = 'x11.11c';
>> if(is_numeric($a)) { echo 'ok'; } else { echo 'not okay'; }
>>
>> Sorry, hit send too quick!
>>
>
> No, Richard had it correct. The if statement returns false, which is
> 'ok'. Your code would return 'not ok' - which is incorrect.
>
norman@amd64x2:~$ php -a
Interactive shell
php > $a = 'x';
php > if(is_numeric($a)) { echo 'okay'; } else { echo 'not okay'; }
not okay
php > $a = '11';
php > if(is_numeric($a)) { echo 'okay'; } else { echo 'not okay'; }
okay
php > $a = 'x11.11c';
php > if(is_numeric($a)) { echo 'okay'; } else { echo 'not okay'; }
not okay
php > $a = '0x1111c';
php > if(is_numeric($a)) { echo 'okay'; } else { echo 'not okay'; }
okay
As per http://us3.php.net/manual/en/function.is-numeric.php :
"Hexadecimal (e.g. 0xf4c3b00c), Binary (e.g. 0b10100111001), Octal (e.g.
0777) notation is allowed too but only without sign, decimal and
exponential part."
--
Norman
Registered Linux user #461062
-Have you been to www.php.net yet?-
|
|
|
|
| Re: bug in is_numeric [message #181396 is a reply to message #181394] |
Wed, 15 May 2013 10:11 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 5/15/2013 5:48 AM, SwissCheese wrote:
> On 05/14/2013 11:01 PM, Jerry Stuckle wrote:
>> On 5/14/2013 9:43 PM, SwissCheese wrote:
>>> On 05/14/2013 09:41 AM, Richard Yates wrote:
>>>> On Mon, 13 May 2013 15:15:06 +0100, fred <email(at)address(dot)com> wrote:
>>>>
>>>> > In article <kmqs3c$e3s$1(at)dont-email(dot)me>, jstucklex(at)attglobal(dot)net
>>>> > says...
>>>> >> As others have shown, is_numeric() returns false in several versions
>>>> >> of PHP.
>>>> >>
>>>> >
>>>> > I have just typed in an exact copy of the test in my message of
>>>> > 02:58pm
>>>> > When you have run that on an apache PHP installation of the same
>>>> > version
>>>> > PHP as I listed (5.3.6) under windows7-64 bit - get back to me.
>>>> >
>>>> > Otherwise I'm done repeating myself.
>>>> >
>>>>
>>>> <?php
>>>> $a = 'x11.11c';
>>>> if(is_numeric($a)) { echo 'oops - a problem'; } else { echo 'okay'; }
>>>> ?>
>>>>
>>>> Prints 'okay'
>>>>
>>>> Windows 7 Home Premium 64 bit, PHP5.3.4, Apache2.2.17, (WAMP)
>>>>
>>>
>>> That's backwards... you want:
>>>
>>> $a = 'x11.11c';
>>> if(is_numeric($a)) { echo 'ok'; } else { echo 'not okay'; }
>>>
>>> Sorry, hit send too quick!
>>>
>>
>> No, Richard had it correct. The if statement returns false, which is
>> 'ok'. Your code would return 'not ok' - which is incorrect.
>>
>
> norman@amd64x2:~$ php -a
> Interactive shell
>
> php > $a = 'x';
> php > if(is_numeric($a)) { echo 'okay'; } else { echo 'not okay'; }
> not okay
> php > $a = '11';
> php > if(is_numeric($a)) { echo 'okay'; } else { echo 'not okay'; }
> okay
> php > $a = 'x11.11c';
> php > if(is_numeric($a)) { echo 'okay'; } else { echo 'not okay'; }
> not okay
> php > $a = '0x1111c';
> php > if(is_numeric($a)) { echo 'okay'; } else { echo 'not okay'; }
> okay
>
>
> As per http://us3.php.net/manual/en/function.is-numeric.php :
>
> "Hexadecimal (e.g. 0xf4c3b00c), Binary (e.g. 0b10100111001), Octal (e.g.
> 0777) notation is allowed too but only without sign, decimal and
> exponential part."
>
>
>
Yes, I know how is_numeric() works. But you don't understand what his
code was doing.
Saying 'not ok' indicates is_numeric is broken - not that the value is
not numeric. is_numeric() is not broken, so saying 'not ok' is the
incorrect message.
It is not saying the value is numeric.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
|
|
| Re: bug in is_numeric [message #181402 is a reply to message #181400] |
Wed, 15 May 2013 11:11 |
Erwin Moller
Messages: 228
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 5/15/2013 12:27 PM, Jerry Stuckle wrote:
> On 5/15/2013 2:05 AM, Sandman wrote:
>> In article <MPG(dot)2bfc50d788d40d139896b3(at)news(dot)virginmedia(dot)com>,
>> fred <email(at)address(dot)com> wrote:
>>
>>> I can't work out if you're all a bunch of mentally deficient half wits
>>> or just too stupid to run a correct test.
>>
>> A "correct test" has been run by almost ten people now.
>>
>>> Either way its been reported I'm no longer interested.
>>
>>
>>
>>
>
> My suspicion is that he found his problem, and it was not in
> is_numeric(). But he doesn't want to admit it.
Yes, I suspect the same.
This Fred seems to have some attitude issues.
He is propably too proud to admit he screwed up the variable to be tested.
Well, not a big loss IMHO, since he lacked the logical skills to see
that he showed himself with Salvatore's test that his is_numeric()
worked alright. ;-)
Regards,
Erwin Moller
>
> Nothing's been reported in the bugs database for the last week.
>
--
"That which can be asserted without evidence, can be dismissed without
evidence."
-- Christopher Hitchens
|
|
|
|
| Re: bug in is_numeric [message #181405 is a reply to message #181394] |
Wed, 15 May 2013 13:19 |
Thomas 'PointedEars'
Messages: 701
Registered: October 2010
Karma: 0
|
Senior Member |
|
|
SwissCheese wrote:
> norman@amd64x2:~$ php -a
> Interactive shell
>
> php > $a = 'x';
> php > if(is_numeric($a)) { echo 'okay'; } else { echo 'not okay'; }
> not okay
> php > $a = '11';
> php > if(is_numeric($a)) { echo 'okay'; } else { echo 'not okay'; }
> okay
> php > $a = 'x11.11c';
> php > if(is_numeric($a)) { echo 'okay'; } else { echo 'not okay'; }
> not okay
> php > $a = '0x1111c';
> php > if(is_numeric($a)) { echo 'okay'; } else { echo 'not okay'; }
> okay
>
>
> As per http://us3.php.net/manual/en/function.is-numeric.php :
>
> "Hexadecimal (e.g. 0xf4c3b00c), Binary (e.g. 0b10100111001), Octal (e.g.
> 0777) notation is allowed too but only without sign, decimal and
> exponential part."
But AISB, the implementation is contradicting the documentation (or vice-
versa) because the a string argument containing the binary format causes
is_numeric() to return FALSE in PHP 5.4.4 and PHP 5.4.14 (when according to
the above it should have returned TRUE). It is not possible to determine by
testing whether the octal format is considered numeric because of itself or
because it is considered decimal. Incidentally, you have neglected to test
those two formats.
PointedEars
--
Danny Goodman's books are out of date and teach practices that are
positively harmful for cross-browser scripting.
-- Richard Cornford, cljs, <cife6q$253$1$8300dec7(at)news(dot)demon(dot)co(dot)uk> (2004)
|
|
|
|
| Re: bug in is_numeric [message #181411 is a reply to message #181405] |
Wed, 15 May 2013 18:23 |
Christoph Becker
Messages: 91
Registered: June 2012
Karma: 0
|
Member |
|
|
Thomas 'PointedEars' Lahn wrote:
> SwissCheese wrote:
>
>> norman@amd64x2:~$ php -a
>> Interactive shell
>>
>> php > $a = 'x';
>> php > if(is_numeric($a)) { echo 'okay'; } else { echo 'not okay'; }
>> not okay
>> php > $a = '11';
>> php > if(is_numeric($a)) { echo 'okay'; } else { echo 'not okay'; }
>> okay
>> php > $a = 'x11.11c';
>> php > if(is_numeric($a)) { echo 'okay'; } else { echo 'not okay'; }
>> not okay
>> php > $a = '0x1111c';
>> php > if(is_numeric($a)) { echo 'okay'; } else { echo 'not okay'; }
>> okay
>>
>>
>> As per http://us3.php.net/manual/en/function.is-numeric.php :
>>
>> "Hexadecimal (e.g. 0xf4c3b00c), Binary (e.g. 0b10100111001), Octal (e.g.
>> 0777) notation is allowed too but only without sign, decimal and
>> exponential part."
>
> But AISB, the implementation is contradicting the documentation (or vice-
> versa) because the a string argument containing the binary format causes
> is_numeric() to return FALSE in PHP 5.4.4 and PHP 5.4.14 (when according to
> the above it should have returned TRUE).
I can confirm issues with is_numeric() wrt. strings in binary notation
in PHP 5.4.7:
>>> is_numeric('0b1010')
false
>>> is_numeric(0b1010)
true
> It is not possible to determine by
> testing whether the octal format is considered numeric because of itself or
> because it is considered decimal.
ACK
> Incidentally, you have neglected to test
> those two formats.
--
Christoph M. Becker
|
|
|
|
| Re: bug in is_numeric [message #181413 is a reply to message #181411] |
Wed, 15 May 2013 18:49 |
Thomas 'PointedEars'
Messages: 701
Registered: October 2010
Karma: 0
|
Senior Member |
|
|
Christoph Becker wrote:
> Thomas 'PointedEars' Lahn wrote:
>> SwissCheese wrote:
>>> norman@amd64x2:~$ php -a
>>> Interactive shell
>>>
>>> php > $a = 'x';
>>> php > if(is_numeric($a)) { echo 'okay'; } else { echo 'not okay'; }
>>> not okay
>>> php > $a = '11';
>>> php > if(is_numeric($a)) { echo 'okay'; } else { echo 'not okay'; }
>>> okay
>>> php > $a = 'x11.11c';
>>> php > if(is_numeric($a)) { echo 'okay'; } else { echo 'not okay'; }
>>> not okay
>>> php > $a = '0x1111c';
>>> php > if(is_numeric($a)) { echo 'okay'; } else { echo 'not okay'; }
>>> okay
>>>
>>> As per http://us3.php.net/manual/en/function.is-numeric.php :
>>>
>>> "Hexadecimal (e.g. 0xf4c3b00c), Binary (e.g. 0b10100111001), Octal (e.g.
>>> 0777) notation is allowed too but only without sign, decimal and
>>> exponential part."
>>
>> But AISB, the implementation is contradicting the documentation (or vice-
>> versa) because the a string argument containing the binary format causes
>> is_numeric() to return FALSE in PHP 5.4.4 and PHP 5.4.14 (when according
5.4.15(-1; Debian), not .14
>> to the above it should have returned TRUE).
>
> I can confirm issues with is_numeric() wrt. strings in binary notation
> in PHP 5.4.7:
>
>>>> is_numeric('0b1010')
> false
>>>> is_numeric(0b1010)
> true
ACK. However, it is unsurprising to me that the latter would return TRUE
because there the literal is parsed into an “int” value *before* it is
passed to is_numeric(), the equivalent of is_numeric(10).
I would rather the former bug was an implementation bug instead of a
documentation bug, because such a function should either work for all
supported numeric representations of the programming language, or there
should be a parameter specifying which representations are supported for the
specific call [like ECMAScripts parseInt(number : String, base : Number) :
Number].
PointedEars
--
Sometimes, what you learn is wrong. If those wrong ideas are close to the
root of the knowledge tree you build on a particular subject, pruning the
bad branches can sometimes cause the whole tree to collapse.
-- Mike Duffy in cljs, <news:Xns9FB6521286DB8invalidcom(at)94(dot)75(dot)214(dot)39>
|
|
|
|
| Re: bug in is_numeric [message #181416 is a reply to message #181413] |
Wed, 15 May 2013 19:58 |
Christoph Becker
Messages: 91
Registered: June 2012
Karma: 0
|
Member |
|
|
Thomas 'PointedEars' Lahn wrote:
> I would rather the former bug was an implementation bug instead of a
> documentation bug, because such a function should either work for all
> supported numeric representations of the programming language, or there
> should be a parameter specifying which representations are supported for the
> specific call [like ECMAScripts parseInt(number : String, base : Number) :
> Number].
ACK. However, the usefulness of is_numeric() returning true for strings
in binary notation is somewhat doubtful, as there is no simple way to
actually convert such strings to a number:
>>> (int) '0b1010'
0
>>> intval('0b1010')
0
>>> intval('0b1010', 2)
0
>>> 0 + '0b1010'
0
So the issue *might* as well be regarded as documentation bug.
BTW: I can confirm the same behavior in PHP 5.2.17 (Windows VC6 build).
--
Christoph M. Becker
|
|
|
|
| Re: bug in is_numeric [message #181417 is a reply to message #181416] |
Wed, 15 May 2013 20:20 |
Thomas 'PointedEars'
Messages: 701
Registered: October 2010
Karma: 0
|
Senior Member |
|
|
Christoph Becker wrote:
> Thomas 'PointedEars' Lahn wrote:
>> I would rather the former bug was an implementation bug instead of a
>> documentation bug, because such a function should either work for all
>> supported numeric representations of the programming language, or there
>> should be a parameter specifying which representations are supported for
>> the specific call [like ECMAScripts parseInt(number : String, base :
>> Number) : Number].
>
> ACK. However, the usefulness of is_numeric() returning true for strings
> in binary notation is somewhat doubtful, as there is no simple way to
> actually convert such strings to a number:
>
>>>> (int) '0b1010'
> 0
>>>> intval('0b1010')
> 0
>>>> intval('0b1010', 2)
> 0
>>>> 0 + '0b1010'
> 0
>
> So the issue *might* as well be regarded as documentation bug.
ISTM to be strong indication that it is an implementation bug, where
the bug would be that the conversion from string to int is incomplete:
$ php -r 'var_dump(+"0x2A");'
int(42)
(as expected)
$ php -r 'var_dump(+"010");'
int(10)
(expected: 8)
A possibility for conversion is:
$ php -r 'var_dump(eval("return " . "0b1110" . ";"));'
int(14)
> BTW: I can confirm the same behavior in PHP 5.2.17 (Windows VC6 build).
Bogus because binary numeric literals were introduced in PHP 5.4.
PointedEars
--
When all you know is jQuery, every problem looks $(olvable).
|
|
|
|
| Re: bug in is_numeric [message #181420 is a reply to message #181417] |
Wed, 15 May 2013 20:42 |
Christoph Becker
Messages: 91
Registered: June 2012
Karma: 0
|
Member |
|
|
Thomas 'PointedEars' Lahn wrote:
> Christoph Becker wrote:
>
>> Thomas 'PointedEars' Lahn wrote:
>>> I would rather the former bug was an implementation bug instead of a
>>> documentation bug, because such a function should either work for all
>>> supported numeric representations of the programming language, or there
>>> should be a parameter specifying which representations are supported for
>>> the specific call [like ECMAScripts parseInt(number : String, base :
>>> Number) : Number].
>>
>> ACK. However, the usefulness of is_numeric() returning true for strings
>> in binary notation is somewhat doubtful, as there is no simple way to
>> actually convert such strings to a number:
>>
>>>> > (int) '0b1010'
>> 0
>>>> > intval('0b1010')
>> 0
>>>> > intval('0b1010', 2)
>> 0
>>>> > 0 + '0b1010'
>> 0
>>
>> So the issue *might* as well be regarded as documentation bug.
>
> ISTM to be strong indication that it is an implementation bug, where
> the bug would be that the conversion from string to int is incomplete:
>
> $ php -r 'var_dump(+"0x2A");'
> int(42)
>
> (as expected)
>
> $ php -r 'var_dump(+"010");'
> int(10)
>
> (expected: 8)
Interestingly the type cast to int has another result:
$ php -r 'var_dump((int) "0x2A");'
int(0)
In bug report #52950[1] the latter behavior is reported as expected.
IMO the former behavior is more useful and consistent. Anyway, the
explicit type cast and the implicit type juggling should have the same
result.
> A possibility for conversion is:
>
> $ php -r 'var_dump(eval("return " . "0b1110" . ";"));'
> int(14)
Ugly, but effective.
>> BTW: I can confirm the same behavior in PHP 5.2.17 (Windows VC6 build).
>
> Bogus because binary numeric literals were introduced in PHP 5.4.
I wasn't aware of that. Thanks for pointing it out.
[1] <https://bugs.php.net/bug.php?id=52950>
--
Christoph M. Becker
|
|
|
|
| Re: bug in is_numeric [message #181425 is a reply to message #181416] |
Wed, 15 May 2013 21:53 |
Thomas Mlynarczyk
Messages: 131
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
Christoph Becker schrieb:
> ACK. However, the usefulness of is_numeric() returning true for strings
> in binary notation is somewhat doubtful, as there is no simple way to
> actually convert such strings to a number:
>
>>>> (int) '0b1010'
> 0
>>>> intval('0b1010')
> 0
>>>> intval('0b1010', 2)
> 0
>>>> 0 + '0b1010'
> 0
bindec( '0b1010' )
Greetings,
Thomas
--
Ce n'est pas parce qu'ils sont nombreux à avoir tort qu'ils ont raison!
(Coluche)
|
|
|
|
| Re: bug in is_numeric [message #181426 is a reply to message #181425] |
Wed, 15 May 2013 22:29 |
Christoph Becker
Messages: 91
Registered: June 2012
Karma: 0
|
Member |
|
|
Thomas Mlynarczyk wrote:
> Christoph Becker schrieb:
>> ACK. However, the usefulness of is_numeric() returning true for strings
>> in binary notation is somewhat doubtful, as there is no simple way to
>> actually convert such strings to a number:
>>
>>>> > (int) '0b1010'
>> 0
>>>> > intval('0b1010')
>> 0
>>>> > intval('0b1010', 2)
>> 0
>>>> > 0 + '0b1010'
>> 0
>
> bindec( '0b1010' )
Nice -- thanks for pointing it out. :)
But what's that:
> php -r "var_dump(bindec('foo1010bar'));"
int(10)
It seems bindec() ignores any leading and trailing characters that are
neither 0 or 1.
So, bindec() doesn't seem to be useful for a routine, which would
convert an arbitrary numeric string to an integer.
--
Christoph M. Becker
|
|
|
|
| Re: bug in is_numeric [message #181427 is a reply to message #181426] |
Wed, 15 May 2013 22:40 |
Christoph Becker
Messages: 91
Registered: June 2012
Karma: 0
|
Member |
|
|
Christoph Becker misquoted:
>> php -r "var_dump(bindec('foo1010bar'));"
> int(10)
Sorry for having used an > sign, which might be confused with a quote.
It should have been:
$ php -r 'var_dump(bindec("foo1010bar"));'
int(10)
--
Christoph M. Becker
|
|
|
|
| Re: bug in is_numeric [message #181433 is a reply to message #181386] |
Thu, 16 May 2013 00:57 |
SwissCheese
Messages: 17
Registered: December 2012
Karma: 0
|
Junior Member |
|
|
On 05/14/2013 11:01 PM, Jerry Stuckle wrote:
> On 5/14/2013 9:43 PM, SwissCheese wrote:
>> On 05/14/2013 09:41 AM, Richard Yates wrote:
>>> On Mon, 13 May 2013 15:15:06 +0100, fred <email(at)address(dot)com> wrote:
>>>
>>>> In article <kmqs3c$e3s$1(at)dont-email(dot)me>, jstucklex(at)attglobal(dot)net
>>>> says...
>>>> > As others have shown, is_numeric() returns false in several versions
>>>> > of PHP.
>>>> >
>>>>
>>>> I have just typed in an exact copy of the test in my message of 02:58pm
>>>> When you have run that on an apache PHP installation of the same
>>>> version
>>>> PHP as I listed (5.3.6) under windows7-64 bit - get back to me.
>>>>
>>>> Otherwise I'm done repeating myself.
>>>>
>>>
>>> <?php
>>> $a = 'x11.11c';
>>> if(is_numeric($a)) { echo 'oops - a problem'; } else { echo 'okay'; }
>>> ?>
>>>
>>> Prints 'okay'
>>>
>>> Windows 7 Home Premium 64 bit, PHP5.3.4, Apache2.2.17, (WAMP)
>>>
>>
>> That's backwards... you want:
>>
>> $a = 'x11.11c';
>> if(is_numeric($a)) { echo 'ok'; } else { echo 'not okay'; }
>>
>> Sorry, hit send too quick!
>>
>
> No, Richard had it correct. The if statement returns false, which is
> 'ok'. Your code would return 'not ok' - which is incorrect.
>
If $a ('x11.11c') is numeric then it would return 'ok' but it is not so
it returns 'not ok'. 'x11.11c' is not hexadecimal, it lacks the leading
'0' and contains a decimal/period.
php > $tests =
array("42",1337,"0xf4c3b00c","x11.11c","0x11.11c","0x1111c","0b1010 ",
" 101010101010101010101010101010101010101010101010101010101010101010101010101 01010101010 ");
php > foreach ($tests as $a) { if(is_numeric($a)) { echo "$a is
numeric".PHP_EOL; } else { echo "$a is not numeric".PHP_EOL; } }
42 is numeric
1337 is numeric
0xf4c3b00c is numeric
x11.11c is not numeric
0x11.11c is not numeric
0x1111c is numeric
0b1010 is not numeric
101010101010101010101010101010101010101010101010101010101010101010101010101 01010101010
is numeric
From what I can tell from the source code (of PHP) there is no code
to handle binary strings as explained in the function definition at
php.net. But I guess by definition it can only be 0's and 1's as seen
above.
--
Norman
Registered Linux user #461062
-Have you been to www.php.net yet?-
|
|
|
|
| Re: bug in is_numeric [message #181435 is a reply to message #181426] |
Thu, 16 May 2013 03:00 |
Thomas 'PointedEars'
Messages: 701
Registered: October 2010
Karma: 0
|
Senior Member |
|
|
Christoph Becker wrote:
> Thomas Mlynarczyk wrote:
>> Christoph Becker schrieb:
>>> ACK. However, the usefulness of is_numeric() returning true for strings
>>> in binary notation is somewhat doubtful, as there is no simple way to
>>> actually convert such strings to a number:
>>>
>>>> >> (int) '0b1010'
>>> 0
>>>> >> intval('0b1010')
>>> 0
>>>> >> intval('0b1010', 2)
>>> 0
>>>> >> 0 + '0b1010'
>>> 0
>>
>> bindec( '0b1010' )
>
> Nice -- thanks for pointing it out. :)
ACK.
> But what's that:
>
> php -r "var_dump(bindec('foo1010bar'));"
> int(10)
>
> It seems bindec() ignores any leading and trailing characters that are
> neither 0 or 1.
>
> So, bindec() doesn't seem to be useful for a routine, which would
^
> convert an arbitrary numeric string to an integer.
True. But, on the other hand, it is not supposed to.
PointedEars
--
Danny Goodman's books are out of date and teach practices that are
positively harmful for cross-browser scripting.
-- Richard Cornford, cljs, <cife6q$253$1$8300dec7(at)news(dot)demon(dot)co(dot)uk> (2004)
|
|
|
|
| Re: bug in is_numeric [message #181436 is a reply to message #181433] |
Thu, 16 May 2013 04:09 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 5/15/2013 8:57 PM, SwissCheese wrote:
> On 05/14/2013 11:01 PM, Jerry Stuckle wrote:
>> On 5/14/2013 9:43 PM, SwissCheese wrote:
>>> On 05/14/2013 09:41 AM, Richard Yates wrote:
>>>> On Mon, 13 May 2013 15:15:06 +0100, fred <email(at)address(dot)com> wrote:
>>>>
>>>> > In article <kmqs3c$e3s$1(at)dont-email(dot)me>, jstucklex(at)attglobal(dot)net
>>>> > says...
>>>> >> As others have shown, is_numeric() returns false in several versions
>>>> >> of PHP.
>>>> >>
>>>> >
>>>> > I have just typed in an exact copy of the test in my message of
>>>> > 02:58pm
>>>> > When you have run that on an apache PHP installation of the same
>>>> > version
>>>> > PHP as I listed (5.3.6) under windows7-64 bit - get back to me.
>>>> >
>>>> > Otherwise I'm done repeating myself.
>>>> >
>>>>
>>>> <?php
>>>> $a = 'x11.11c';
>>>> if(is_numeric($a)) { echo 'oops - a problem'; } else { echo 'okay'; }
>>>> ?>
>>>>
>>>> Prints 'okay'
>>>>
>>>> Windows 7 Home Premium 64 bit, PHP5.3.4, Apache2.2.17, (WAMP)
>>>>
>>>
>>> That's backwards... you want:
>>>
>>> $a = 'x11.11c';
>>> if(is_numeric($a)) { echo 'ok'; } else { echo 'not okay'; }
>>>
>>> Sorry, hit send too quick!
>>>
>>
>> No, Richard had it correct. The if statement returns false, which is
>> 'ok'. Your code would return 'not ok' - which is incorrect.
>>
>
> If $a ('x11.11c') is numeric then it would return 'ok' but it is not so
> it returns 'not ok'. 'x11.11c' is not hexadecimal, it lacks the leading
> '0' and contains a decimal/period.
>
'ok' is correct in this instance. is_numeric() should NOT return a
numeric value; if it did, that would be incorrect.
You are confusing 'not numeric' with 'not ok'. The first would return
whether the value is numeric or not. The second returns whether the
function returns the correct value or not.
The correct value is that the parameter is NOT a valid numeric value, so
'ok' (the function worked correctly) is the correct response.
> php > $tests =
> array("42",1337,"0xf4c3b00c","x11.11c","0x11.11c","0x1111c","0b1010 ",
> " 101010101010101010101010101010101010101010101010101010101010101010101010101 01010101010 ");
>
> php > foreach ($tests as $a) { if(is_numeric($a)) { echo "$a is
> numeric".PHP_EOL; } else { echo "$a is not numeric".PHP_EOL; } }
> 42 is numeric
> 1337 is numeric
> 0xf4c3b00c is numeric
> x11.11c is not numeric
> 0x11.11c is not numeric
> 0x1111c is numeric
> 0b1010 is not numeric
> 101010101010101010101010101010101010101010101010101010101010101010101010101 01010101010
> is numeric
>
>
> From what I can tell from the source code (of PHP) there is no code
> to handle binary strings as explained in the function definition at
> php.net. But I guess by definition it can only be 0's and 1's as seen
> above.
>
>
>
Binary strings are a completely different problem introduces by the
troll 'Pointed Head' which has nothing to do with the OP's problem. But
then 'Pointed Head' is notorious (in several newsgroups) for hijacking
threads for his own purpose.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: bug in is_numeric [message #181445 is a reply to message #181413] |
Thu, 16 May 2013 22:16 |
SwissCheese
Messages: 17
Registered: December 2012
Karma: 0
|
Junior Member |
|
|
On 05/15/2013 02:49 PM, Thomas 'PointedEars' Lahn wrote:
> Christoph Becker wrote:
>
>> Thomas 'PointedEars' Lahn wrote:
>>> SwissCheese wrote:
>>>> norman@amd64x2:~$ php -a
>>>> Interactive shell
>>>>
>>>> php > $a = 'x';
>>>> php > if(is_numeric($a)) { echo 'okay'; } else { echo 'not okay'; }
>>>> not okay
>>>> php > $a = '11';
>>>> php > if(is_numeric($a)) { echo 'okay'; } else { echo 'not okay'; }
>>>> okay
>>>> php > $a = 'x11.11c';
>>>> php > if(is_numeric($a)) { echo 'okay'; } else { echo 'not okay'; }
>>>> not okay
>>>> php > $a = '0x1111c';
>>>> php > if(is_numeric($a)) { echo 'okay'; } else { echo 'not okay'; }
>>>> okay
>>>>
>>>> As per http://us3.php.net/manual/en/function.is-numeric.php :
>>>>
>>>> "Hexadecimal (e.g. 0xf4c3b00c), Binary (e.g. 0b10100111001), Octal (e.g.
>>>> 0777) notation is allowed too but only without sign, decimal and
>>>> exponential part."
>>>
>>> But AISB, the implementation is contradicting the documentation (or vice-
>>> versa) because the a string argument containing the binary format causes
>>> is_numeric() to return FALSE in PHP 5.4.4 and PHP 5.4.14 (when according
>
> 5.4.15(-1; Debian), not .14
>
>>> to the above it should have returned TRUE).
>>
>> I can confirm issues with is_numeric() wrt. strings in binary notation
>> in PHP 5.4.7:
>>
>>>> > is_numeric('0b1010')
>> false
>>>> > is_numeric(0b1010)
>> true
>
> ACK. However, it is unsurprising to me that the latter would return TRUE
> because there the literal is parsed into an “int” value *before* it is
> passed to is_numeric(), the equivalent of is_numeric(10).
>
> I would rather the former bug was an implementation bug instead of a
> documentation bug, because such a function should either work for all
> supported numeric representations of the programming language, or there
> should be a parameter specifying which representations are supported for the
> specific call [like ECMAScripts parseInt(number : String, base : Number) :
> Number].
>
>
> PointedEars
>
Thomas,
Looking into the source (PHP) there is no code to support binary
strings of the type '0b1010101'. The code for hexadecimal is there however.
php > $tests =
array("42",1337,"0xf4c3b00c","x11.11c","0x11.11c","0x1111c","0b1010 ","0b10101",
" 101010101010101010101010101010101010101010101010101010101010101010101010101 01010101010 ",
"0700");
php > foreach ($tests as $a) { if(is_numeric($a)) { echo "$a is numeric
".var_dump(is_numeric($a)).PHP_EOL; } else { echo "$a is not
numeric".var_dump(is_numeric($a)).PHP_EOL; } }
bool(true)
42 is numeric
bool(true)
1337 is numeric
bool(true)
0xf4c3b00c is numeric
bool(false)
x11.11c is not numeric
bool(false)
0x11.11c is not numeric
bool(true)
0x1111c is numeric
bool(false)
0b1010 is not numeric
bool(false)
0b10101 is not numeric
bool(true)
101010101010101010101010101010101010101010101010101010101010101010101010101 01010101010
is numeric
bool(true)
0700 is numeric
--
Norman
Registered Linux user #461062
-Have you been to www.php.net yet?-
|
|
|
|
| Re: bug in is_numeric [message #181446 is a reply to message #181341] |
Thu, 16 May 2013 22:28 |
SwissCheese
Messages: 17
Registered: December 2012
Karma: 0
|
Junior Member |
|
|
On 05/13/2013 05:07 AM, Thomas 'PointedEars' Lahn wrote:
> Jerry Stuckle wrote:
>
>> On 5/12/2013 7:27 PM, Thomas 'PointedEars' Lahn wrote:
>>> Jerry Stuckle wrote:
>>>> On 5/12/2013 2:39 PM, Thomas 'PointedEars' Lahn wrote:
>>>> > Jerry Stuckle wrote:
>>>> >> On 5/12/2013 1:38 PM, Thomas 'PointedEars' Lahn wrote:
>>>> >>> Thomas Mlynarczyk wrote:
>>>> >>>> Sanders Kaufman schrieb:
>>>> >>>>>> if(is_numeric('x11.11c') returns TRUE
>>>> >>>>> Try it without the quotation marks around the number.
>>>> >>>>
>>>> >>>> Which number? x11.11c is not a number.
>>>> >>>
>>>> >>> The misconception might partially draw from the fact that 0x11 is a
>>>> >>> number, the hexadecimal representation of decimal 16¹ + 16⁰ = 17
>>>> >>> (even in PHP).
>
> To be clear, I was referring to *Sanders'* misconception.
>
>>>> >>> In other programming languages that require a leading
>>>> >>> “0” and do not have “.” as (concatenation) operator,
>>>> >>>
>>>> >>> x11.11c
>>>> >>>
>>>> >>> could be the representation of decimal 16¹ + 16⁰ + 16⁻¹ + 16⁻² + 13 ×
>>>> >>> 16⁻³ = 17.06958 (BTW, I have written a drop-in replacement for
>>>> >>> ECMAScript's parseFloat() that can do that, with the usual rounding
>>>> >>> errors [1]).
>>>> >>>
>>>> >>> In PHP, however,
>>>> >>>
>>>> >>> x11.11c
>>>> >>>
>>>> >>> would be equivalent to
>>>> >>>
>>>> >>> (x11) . (11c)
>>>> >>>
>>>> >>
>>>> >> Wrong, as usual.
>>>> >>
>>>> >> <snip>
>>>> >
>>>> > Intentionally misquoted, as usual.
>>>>
>>>> And exactly what is wrong with what I quoted?
>>>
>>> In contrast to what you stated, exactly *nothing* is wrong with it when
>>> properly quoted; that is, *in context*, which is the point. Giving you
>>> the benefit of a doubt, you appear to have severe difficulty
>>> understanding the concept of context as such and the importance of
>>> context in quotations specifically; it would be good if you could work on
>>> that.
>>
>> That was the beginning of your reply. There was no previous context to
>> quote.
>
> It was the text that *followed*, and that you snipped, that put the part of
> my statement that you quoted, in context.
>
>>>> The rest of your trash
>>>
>>> Not everything that you choose to ignore or fail to understand is “trash”
>>> because of that.
>>
>> No, but almost *everything* you say is pure tripe. You can't blame this
>> on the "context".
>
> You proceed from the false assumption that if someone is wrong on one thing
> (and to date we have only *your* *opinion* on that) must be wrong on
> another.
>
>>>> was based on this incorrect premise; it would be a waste of bandwidth to
>>>> repost your entire tripe.
>>> As showed by the PHP output that I posted further below, and that you
>>> snipped, the premise is _not_ incorrect. To elaborate:
>>
>> The premise is completely incorrect. 'x11.11c' is NEVER considered a
>> numeric value, as several other people (including me) have shown. And
>> the '.' is NEVER an operator when within a quoted string.
>
> Apparently you do not understand that is_numeric() treats both numeric
> literals and numeric representations in string literals the same. Therefore
> it matters to the return value of is_numeric() if string content could be a
> numeric literal when used verbatim in PHP code. I have showed that and why
> it could not be a numeric literal, providing the rationale for the return
> value of is_numeric().
>
>>> As a result, “x11“ would be considered a constant's identifier; because
>>> such a constant would likele be undeclared, it would be parsed as if it
>>> was a string value containing the characters of the would-be identifier
>>> as characters (see the PHP Notices in the test, and the generated output
>>> for proof of that).
>>
>> Nope, not unless there was a define ('x11',...) statement previous to
>> this. It is a string - plain and simple. […]
>
> The PHP output that I posted shows that a standalone identifier – such *as
> if* that string *content* was used in PHP code is met with a PHP Notice and
> is *treated as* I described above from then on. The Notice is issued then
> because the source code is ambiguous, therefore error-prone. As you
> confirmed, if a constant having that sequence of identifiers would be
> declared, the source code would change meaning.
>
> This is important because if a sequence of characters is potentially a
> constant identifier, it cannot be a numeric literal at the same time.
>
>>> “11c” would be considered a constant identifier as well (and treated the
>>> same way) if it did not start with a decimal digit. Or it would be
>>> considered a decimal literal if it did not contain/end with “c” (allowed
>>> would only be “e” followed by a decimal literal, for the
>>> exponential/scientific decimal format). But as it does contain/end with
>>> “c”
>>> that is not in a hexadecimal literal, it is a *syntax error*. Therefore,
>>> the entire expression would not compile and the entire PHP program would
>>> not compile, being syntactically in error.
>>
>> Wrong again. In PHP you have to have a define() statement to create a
>> constant. It is part of string. […]
>
> I am aware that one needs define() for constants. This has nothing to do
> with the fact that an identifier is treated as a string value containing the
> identifiers characters if there is no constant declared with that
> identifier. And it has nothing to do with the fact that a constant cannot
> start with a decimal digit, or that a decimal literal cannot contain the
> character “c”. That therefore such a PHP program would be syntactical in
> error; that therefore, too, “x11.11c” cannot be a numeric literal, and that
> therefore, too, is_numeric('x11.11c') MUST return FALSE (which, contrary to
> the OP's claims, it does).
>
>>> We have now ascertaine that, as Thomas Mlynarczyk stated, “x11.11c”
>>> cannot be a proper numeric literal in PHP (it would be an operation
>>> expression
>>> [that would not compile, but that is unimportant from here]). As that is
>>> the case, “'x11.11c'” also is not considered numeric in PHP, which is why
>>
>> No, it is a string value, nothing more, nothing less.
>
> It is a string value whose suitability to serve as a numeric value is being
> tested with is_numeric(). Therefore it matters what the PHP grammar has to
> say about numeric values.
>
>>> is_numeric('x11.11c')
>>>
>>> must return FALSE. By contrast, is_numeric('0x11') returns TRUE.
>>
>> is_numeric('0x11') has nothing to do with the problem at hand.
>
> Yes, it has. Both the added “0” prefix and the omitted “.11c” suffix make
> “0x11” a proper numeric (hexadecimal integer) representation as per the PHP
> grammar. Which is what is_numeric() is supposed to test.
>
is_numeric() checks to see if the first two characters are '0x' (or
'0X'), but it does not add a leading '0' if the first character is an
'x' (or 'X')... nor does it simply omit the part that is not a number
'.11c'. is_numeric() checks the string as passed without altering it.
>>> However, there appears to be an *actual* mismatch between PHP manual and
>>> implementation in said PHP version as
>>>
>>> is_numeric('0b11001001')
>>>
>>> returns FALSE when according to the manual it should return TRUE (binary
>>> integer literals are available since PHP 5.4.0 per the manual, and they
>>> do compile and properly evaluate in tests there.
>>
Correct as per my other reply.
>> Again, absolutely nothing to do with this problem.
>
> Yes, it has. The OP claimed there was a bug in is_numeric(). If we assume
> the manual to be correct, this example shows that there actually *would be*
> a bug in is_numeric() in PHP 5.4.4(-15) and 5.4.15(-1 on Debian GNU/Linux).
> But it would be *another* bug.
>
> That might be immaterial to you, but I consider it important for my fellow
> PHP developers to learn of it.
>
>
> PointedEars
>
--
Norman
Registered Linux user #461062
-Have you been to www.php.net yet?-
|
|
|
|
| Re: bug in is_numeric [message #181447 is a reply to message #181446] |
Thu, 16 May 2013 22:33 |
Thomas 'PointedEars'
Messages: 701
Registered: October 2010
Karma: 0
|
Senior Member |
|
|
SwissCheese wrote:
> On 05/13/2013 05:07 AM, Thomas 'PointedEars' Lahn wrote:
>> It is a string value whose suitability to serve as a numeric value is
>> being tested with is_numeric(). Therefore it matters what the PHP
>> grammar has to say about numeric values.
>>
>>>> is_numeric('x11.11c')
>>>>
>>>> must return FALSE. By contrast, is_numeric('0x11') returns TRUE.
>>>
>>> is_numeric('0x11') has nothing to do with the problem at hand.
>>
>> Yes, it has. Both the added “0” prefix and the omitted “.11c” suffix
>> make “0x11” a proper numeric (hexadecimal integer) representation as per
>> the PHP
>> grammar. Which is what is_numeric() is supposed to test.
>
> is_numeric() checks to see if the first two characters are '0x' (or
> '0X'), but it does not add a leading '0' if the first character is an
> 'x' (or 'X')... nor does it simply omit the part that is not a number
> '.11c'. is_numeric() checks the string as passed without altering it.
Aside from getting a real name and learning to quote only the relevant parts
of what you are replying to, you want to learn to read what you quote more
carefully. I have not even implied that is_numeric() adds anything.
>>>> However, there appears to be an *actual* mismatch between PHP manual
>>>> and implementation in said PHP version as
>>>>
>>>> is_numeric('0b11001001')
>>>>
>>>> returns FALSE when according to the manual it should return TRUE
>>>> (binary integer literals are available since PHP 5.4.0 per the manual,
>>>> and they do compile and properly evaluate in tests there.
>
> Correct as per my other reply.
It is not correct if the manual says something else, and it does. Either
the manual or the implementation is wrong.
PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann
|
|
|
|
| Re: bug in is_numeric [message #181448 is a reply to message #181396] |
Thu, 16 May 2013 22:36 |
SwissCheese
Messages: 17
Registered: December 2012
Karma: 0
|
Junior Member |
|
|
On 05/15/2013 06:11 AM, Jerry Stuckle wrote:
> On 5/15/2013 5:48 AM, SwissCheese wrote:
>> On 05/14/2013 11:01 PM, Jerry Stuckle wrote:
>>> On 5/14/2013 9:43 PM, SwissCheese wrote:
>>>> On 05/14/2013 09:41 AM, Richard Yates wrote:
>>>> > On Mon, 13 May 2013 15:15:06 +0100, fred <email(at)address(dot)com> wrote:
>>>> >
>>>> >> In article <kmqs3c$e3s$1(at)dont-email(dot)me>, jstucklex(at)attglobal(dot)net
>>>> >> says...
>>>> >>> As others have shown, is_numeric() returns false in several versions
>>>> >>> of PHP.
>>>> >>>
>>>> >>
>>>> >> I have just typed in an exact copy of the test in my message of
>>>> >> 02:58pm
>>>> >> When you have run that on an apache PHP installation of the same
>>>> >> version
>>>> >> PHP as I listed (5.3.6) under windows7-64 bit - get back to me.
>>>> >>
>>>> >> Otherwise I'm done repeating myself.
>>>> >>
>>>> >
>>>> > <?php
>>>> > $a = 'x11.11c';
>>>> > if(is_numeric($a)) { echo 'oops - a problem'; } else { echo 'okay'; }
>>>> > ?>
>>>> >
>>>> > Prints 'okay'
>>>> >
>>>> > Windows 7 Home Premium 64 bit, PHP5.3.4, Apache2.2.17, (WAMP)
>>>> >
>>>>
>>>> That's backwards... you want:
>>>>
>>>> $a = 'x11.11c';
>>>> if(is_numeric($a)) { echo 'ok'; } else { echo 'not okay'; }
>>>>
>>>> Sorry, hit send too quick!
>>>>
>>>
>>> No, Richard had it correct. The if statement returns false, which is
>>> 'ok'. Your code would return 'not ok' - which is incorrect.
>>>
>>
>> norman@amd64x2:~$ php -a
>> Interactive shell
>>
>> php > $a = 'x';
>> php > if(is_numeric($a)) { echo 'okay'; } else { echo 'not okay'; }
>> not okay
>> php > $a = '11';
>> php > if(is_numeric($a)) { echo 'okay'; } else { echo 'not okay'; }
>> okay
>> php > $a = 'x11.11c';
>> php > if(is_numeric($a)) { echo 'okay'; } else { echo 'not okay'; }
>> not okay
>> php > $a = '0x1111c';
>> php > if(is_numeric($a)) { echo 'okay'; } else { echo 'not okay'; }
>> okay
>>
>>
>> As per http://us3.php.net/manual/en/function.is-numeric.php :
>>
>> "Hexadecimal (e.g. 0xf4c3b00c), Binary (e.g. 0b10100111001), Octal (e.g.
>> 0777) notation is allowed too but only without sign, decimal and
>> exponential part."
>>
>>
>>
>
> Yes, I know how is_numeric() works. But you don't understand what his
> code was doing.
>
> Saying 'not ok' indicates is_numeric is broken - not that the value is
> not numeric. is_numeric() is not broken, so saying 'not ok' is the
> incorrect message.
>
> It is not saying the value is numeric.
>
You know, I've only had to read this post ten times to understand
what you were saying... ;) My thought was that the output was saying the
argument was 'ok' (a number) or 'not ok' (not a number'). I did not
consider the output to be a reflection of the status of is_numeric().
--
Norman
Registered Linux user #461062
-Have you been to www.php.net yet?-
|
|
|
|
| Re: bug in is_numeric [message #181449 is a reply to message #181386] |
Thu, 16 May 2013 22:41 |
SwissCheese
Messages: 17
Registered: December 2012
Karma: 0
|
Junior Member |
|
|
On 05/14/2013 11:01 PM, Jerry Stuckle wrote:
> On 5/14/2013 9:43 PM, SwissCheese wrote:
>> On 05/14/2013 09:41 AM, Richard Yates wrote:
>>> On Mon, 13 May 2013 15:15:06 +0100, fred <email(at)address(dot)com> wrote:
>>>
>>>> In article <kmqs3c$e3s$1(at)dont-email(dot)me>, jstucklex(at)attglobal(dot)net
>>>> says...
>>>> > As others have shown, is_numeric() returns false in several versions
>>>> > of PHP.
>>>> >
>>>>
>>>> I have just typed in an exact copy of the test in my message of 02:58pm
>>>> When you have run that on an apache PHP installation of the same
>>>> version
>>>> PHP as I listed (5.3.6) under windows7-64 bit - get back to me.
>>>>
>>>> Otherwise I'm done repeating myself.
>>>>
>>>
>>> <?php
>>> $a = 'x11.11c';
>>> if(is_numeric($a)) { echo 'oops - a problem'; } else { echo 'okay'; }
>>> ?>
>>>
>>> Prints 'okay'
>>>
>>> Windows 7 Home Premium 64 bit, PHP5.3.4, Apache2.2.17, (WAMP)
>>>
>>
>> That's backwards... you want:
>>
>> $a = 'x11.11c';
>> if(is_numeric($a)) { echo 'ok'; } else { echo 'not okay'; }
>>
>> Sorry, hit send too quick!
>>
>
> No, Richard had it correct. The if statement returns false, which is
> 'ok'. Your code would return 'not ok' - which is incorrect.
>
As per my other reply... my code returns 'not ok' because 'x11.11c'
as a string being evaluated by is_numeric() is not ok. It does not pass
as a valid number. 'not ok' -> 'not numeric'
--
Norman
Registered Linux user #461062
-Have you been to www.php.net yet?-
|
|
|
|
| Re: bug in is_numeric [message #181450 is a reply to message #181445] |
Thu, 16 May 2013 22:45 |
Thomas 'PointedEars'
Messages: 701
Registered: October 2010
Karma: 0
|
Senior Member |
|
|
SwissCheese wrote:
> On 05/15/2013 02:49 PM, Thomas 'PointedEars' Lahn wrote:
>> Christoph Becker wrote:
>>> Thomas 'PointedEars' Lahn wrote:
>>>> to the above it should have returned TRUE).
>>>
>>> I can confirm issues with is_numeric() wrt. strings in binary notation
>>> in PHP 5.4.7:
>>>
>>>> >> is_numeric('0b1010')
>>> false
>>>> >> is_numeric(0b1010)
>>> true
>>
>> ACK. However, it is unsurprising to me that the latter would return TRUE
>> because there the literal is parsed into an “int” value *before* it is
>> passed to is_numeric(), the equivalent of is_numeric(10).
>>
>> I would rather the former bug was an implementation bug instead of a
>> documentation bug, because such a function should either work for all
>> supported numeric representations of the programming language, or there
>> should be a parameter specifying which representations are supported for
>> the specific call [like ECMAScripts parseInt(number : String, base :
>> Number) : Number].
>
> Thomas,
This is NetNews, not e-mail.
> Looking into the source (PHP) there is no code to support binary
> strings of the type '0b1010101'. The code for hexadecimal is there
> however.
AISB, testing with PHP does not help to resolve the basic issue here. From
such tests it is still unclear whether not supporting the binary format is
an implementation bug, i. e. an omission of supporting the binary format
introduced with PHP 5.4; or a documentation bug, i. e. manual claiming that
is_numeric() supports more than it is actually supposed to.
What would be interesting instead is to look at the source code from which
PHP 5.4 and particularly is_numeric() is built as that could at least show
if the octal format would be recognized, and if there was support for the
binary format that was just not properly triggered.
> [Tests]
This was so unnecessary. We have already ascertained how the implementation
works or rather how it does not work. Learn to read for a change, will you?
PointedEars
--
When all you know is jQuery, every problem looks $(olvable).
|
|
|
|
| Re: bug in is_numeric [message #181451 is a reply to message #181436] |
Thu, 16 May 2013 23:17 |
Christoph Becker
Messages: 91
Registered: June 2012
Karma: 0
|
Member |
|
|
Jerry Stuckle wrote:
> Binary strings are a completely different problem introduces by the
> troll 'Pointed Head' which has nothing to do with the OP's problem. But
> then 'Pointed Head' is notorious (in several newsgroups) for hijacking
> threads for his own purpose.
Interestingly enough, the topic of this thread is "bug in is_numeric".
Apparently the only bug of is_numeric() pointed out in this rather
lenghty thread is the behavior regarding numeric strings in binary
notation (and maybe octal notation also).
Indeed, this has nothing to do with the OP's problem, but ISTM that that
was not related to is_numeric() at all.
Anyway, indicating that there's a bug in is_numeric() (or its
documentation) doesn't seem like "hijacking a thread for one's own
purpose" to me. On the contrary, I consider it a valuable contribution.
--
Christoph M. Becker
|
|
|
|
| Re: bug in is_numeric [message #181452 is a reply to message #181451] |
Fri, 17 May 2013 00:30 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 5/16/2013 7:17 PM, Christoph Becker wrote:
> Jerry Stuckle wrote:
>> Binary strings are a completely different problem introduces by the
>> troll 'Pointed Head' which has nothing to do with the OP's problem. But
>> then 'Pointed Head' is notorious (in several newsgroups) for hijacking
>> threads for his own purpose.
>
> Interestingly enough, the topic of this thread is "bug in is_numeric".
> Apparently the only bug of is_numeric() pointed out in this rather
> lenghty thread is the behavior regarding numeric strings in binary
> notation (and maybe octal notation also).
>
> Indeed, this has nothing to do with the OP's problem, but ISTM that that
> was not related to is_numeric() at all.
>
> Anyway, indicating that there's a bug in is_numeric() (or its
> documentation) doesn't seem like "hijacking a thread for one's own
> purpose" to me. On the contrary, I consider it a valuable contribution.
>
No, but since it is unrelated to the OP's problem, it's nothing more
than thread hijacking - something Pointed Head is well known for, as I
said before.
If Pointed Head wanted to bring it up, he should have started a new
thread. Or, better yet, reported it on the PHP bugs database, since
none of the PHP developers pay attention to this newsgroup.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: bug in is_numeric [message #181453 is a reply to message #181447] |
Fri, 17 May 2013 02:34 |
SwissCheese
Messages: 17
Registered: December 2012
Karma: 0
|
Junior Member |
|
|
On 05/16/2013 06:33 PM, Thomas 'PointedEars' Lahn wrote:
> SwissCheese wrote:
>
>> On 05/13/2013 05:07 AM, Thomas 'PointedEars' Lahn wrote:
>>> It is a string value whose suitability to serve as a numeric value is
>>> being tested with is_numeric(). Therefore it matters what the PHP
>>> grammar has to say about numeric values.
>>>
>>>> > is_numeric('x11.11c')
>>>> >
>>>> > must return FALSE. By contrast, is_numeric('0x11') returns TRUE.
>>>>
>>>> is_numeric('0x11') has nothing to do with the problem at hand.
>>>
>>> Yes, it has. Both the added “0” prefix and the omitted “.11c” suffix
>>> make “0x11” a proper numeric (hexadecimal integer) representation as per
>>> the PHP
>>> grammar. Which is what is_numeric() is supposed to test.
>>
>> is_numeric() checks to see if the first two characters are '0x' (or
>> '0X'), but it does not add a leading '0' if the first character is an
>> 'x' (or 'X')... nor does it simply omit the part that is not a number
>> '.11c'. is_numeric() checks the string as passed without altering it.
>
> Aside from getting a real name and learning to quote only the relevant parts
> of what you are replying to, you want to learn to read what you quote more
> carefully. I have not even implied that is_numeric() adds anything.
>
Aside from the fact that I'm fairly sure 'Pointed Ears' is not part
of -your- real name, maybe you would notice that my real name is in my
signature.
>>>> > However, there appears to be an *actual* mismatch between PHP manual
>>>> > and implementation in said PHP version as
>>>> >
>>>> > is_numeric('0b11001001')
>>>> >
>>>> > returns FALSE when according to the manual it should return TRUE
>>>> > (binary integer literals are available since PHP 5.4.0 per the manual,
>>>> > and they do compile and properly evaluate in tests there.
>>
>> Correct as per my other reply.
>
> It is not correct if the manual says something else, and it does. Either
> the manual or the implementation is wrong.
>
>
'Correct' in that the documentation is wrong... as I stated in another
reply.
> PointedEars
>
--
Norman
Registered Linux user #461062
-Have you been to www.php.net yet?-
|
|
|
|
| Re: bug in is_numeric [message #181454 is a reply to message #181450] |
Fri, 17 May 2013 02:52 |
SwissCheese
Messages: 17
Registered: December 2012
Karma: 0
|
Junior Member |
|
|
On 05/16/2013 06:45 PM, Thomas 'PointedEars' Lahn wrote:
> SwissCheese wrote:
>
>> On 05/15/2013 02:49 PM, Thomas 'PointedEars' Lahn wrote:
>>> Christoph Becker wrote:
>>>> Thomas 'PointedEars' Lahn wrote:
>>>> > to the above it should have returned TRUE).
>>>>
>>>> I can confirm issues with is_numeric() wrt. strings in binary notation
>>>> in PHP 5.4.7:
>>>>
>>>> >>> is_numeric('0b1010')
>>>> false
>>>> >>> is_numeric(0b1010)
>>>> true
>>>
>>> ACK. However, it is unsurprising to me that the latter would return TRUE
>>> because there the literal is parsed into an “int” value *before* it is
>>> passed to is_numeric(), the equivalent of is_numeric(10).
>>>
>>> I would rather the former bug was an implementation bug instead of a
>>> documentation bug, because such a function should either work for all
>>> supported numeric representations of the programming language, or there
>>> should be a parameter specifying which representations are supported for
>>> the specific call [like ECMAScripts parseInt(number : String, base :
>>> Number) : Number].
>>
>> Thomas,
>
> This is NetNews, not e-mail.
>
Um, ok. So you chastise people about using real names yet don't want
yours used?
>> Looking into the source (PHP) there is no code to support binary
>> strings of the type '0b1010101'. The code for hexadecimal is there
>> however.
>
> AISB, testing with PHP does not help to resolve the basic issue here. From
> such tests it is still unclear whether not supporting the binary format is
> an implementation bug, i. e. an omission of supporting the binary format
> introduced with PHP 5.4; or a documentation bug, i. e. manual claiming that
> is_numeric() supports more than it is actually supposed to.
>
> What would be interesting instead is to look at the source code from which
> PHP 5.4 and particularly is_numeric() is built as that could at least show
> if the octal format would be recognized, and if there was support for the
> binary format that was just not properly triggered.
>
Isn't that what I just mentioned I did ('Looking into the source
code...') above? There is no support for binary numbers passed as
strings in the form '0b101010'. If you pass 0b101010 (not as a string)
and it gets converted to an (int) on the way in then that's obviously
not the same thing. And what is so special about octal that is_numeric()
would not recognise it?
>> [Tests]
>
> This was so unnecessary. We have already ascertained how the implementation
> works or rather how it does not work. Learn to read for a change, will you?
>
>
> PointedEars
>
Who is this 'PointedEars', get a real name will you?
--
Norman
Registered Linux user #461062
-Have you been to www.php.net yet?-
|
|
|
|
| Re: bug in is_numeric [message #181458 is a reply to message #181454] |
Fri, 17 May 2013 16:33 |
Thomas 'PointedEars'
Messages: 701
Registered: October 2010
Karma: 0
|
Senior Member |
|
|
SwissCheese wrote:
> On 05/16/2013 06:45 PM, Thomas 'PointedEars' Lahn wrote:
>> SwissCheese wrote:
>>> On 05/15/2013 02:49 PM, Thomas 'PointedEars' Lahn wrote:
>>>> Christoph Becker wrote:
>>>> > Thomas 'PointedEars' Lahn wrote:
>>>> >> to the above it should have returned TRUE).
>>>> >
>>>> > I can confirm issues with is_numeric() wrt. strings in binary notation
>>>> > in PHP 5.4.7:
>>>> >
>>>> > >>> is_numeric('0b1010')
>>>> > false
>>>> > >>> is_numeric(0b1010)
>>>> > true
>>>>
>>>> ACK. However, it is unsurprising to me that the latter would return
>>>> TRUE because there the literal is parsed into an “int” value *before*
>>>> it is passed to is_numeric(), the equivalent of is_numeric(10).
>>>>
>>>> I would rather the former bug was an implementation bug instead of a
>>>> documentation bug, because such a function should either work for all
>>>> supported numeric representations of the programming language, or there
>>>> should be a parameter specifying which representations are supported
>>>> for the specific call [like ECMAScripts parseInt(number : String, base
>>>> : Number) : Number].
>>>
>>> Thomas,
>>
>> This is NetNews, not e-mail.
>
> Um, ok. So you chastise people about using real names yet don't want
> yours used?
No, I am reminding you of the fact that I am not the only recipient of your
posting, even though your posting is a follow-up to mine.
>>> Looking into the source (PHP) there is no code to support binary
>>> strings of the type '0b1010101'. The code for hexadecimal is there
>>> however.
>>
>> AISB, testing with PHP does not help to resolve the basic issue here.
>> From such tests it is still unclear whether not supporting the binary
>> format is an implementation bug, i. e. an omission of supporting the
>> binary format introduced with PHP 5.4; or a documentation bug, i. e.
>> manual claiming that is_numeric() supports more than it is actually
>> supposed to.
>>
>> What would be interesting instead is to look at the source code from
>> which PHP 5.4 and particularly is_numeric() is built as that could at
>> least show if the octal format would be recognized, and if there was
>> support for the binary format that was just not properly triggered.
>
> Isn't that what I just mentioned I did ('Looking into the source
> code...') above?
I am not sure. Which source code have you been looking into?
> There is no support for binary numbers passed as strings in the form
> '0b101010'.
You are still missing the point. It is already clear to at least two people
here that there is no support. It is not clear why, as this format for
numeric literals was introduced only recently, and as the documentation
states something else.
> If you pass 0b101010 (not as a string) and it gets converted to an (int)
> on the way in then that's obviously not the same thing.
I am/We are aware of that.
> And what is so special about octal that is_numeric() would not recognise
> it?
It has no “8” figure.
> Who is this 'PointedEars', get a real name will you?
I sign my postings with the nickname under which I am known on the Net.
My first and last name are in the From header field value of my postings,
surrounding my nickname. Yours are not. Thus, you are not posting using
your real name, which is not considered polite on Usenet.
PointedEars
--
> If you get a bunch of authors […] that state the same "best practices"
> in any programming language, then you can bet who is wrong or right...
Not with javascript. Nonsense propagates like wildfire in this field.
-- Richard Cornford, comp.lang.javascript, 2011-11-14
|
|
|
|
| Re: bug in is_numeric [message #181460 is a reply to message #181458] |
Fri, 17 May 2013 18:39 |
Christoph Becker
Messages: 91
Registered: June 2012
Karma: 0
|
Member |
|
|
Thomas 'PointedEars' Lahn wrote:
> SwissCheese wrote:
>
>> Isn't that what I just mentioned I did ('Looking into the source
>> code...') above?
>
> I am not sure. Which source code have you been looking into?
In PHP 5.4 the definition of is_numeric() is in ext/standard/type.c (~
line 300ff)[1]. The relevant function to do the check for arguments of
type string is is_numeric_string_ex() in Zend/zend_operators.h (~ line
109ff)[2]. Apparently special support for strings in binary as well as
octal notation is missing; only strings in decimal and hexadecimal
notation are recognized as such (strings in octal notation are treated
as being decimal).
>> There is no support for binary numbers passed as strings in the form
>> '0b101010'.
>
> You are still missing the point. It is already clear to at least two people
> here that there is no support. It is not clear why, as this format for
> numeric literals was introduced only recently, and as the documentation
> states something else.
>
>> If you pass 0b101010 (not as a string) and it gets converted to an (int)
>> on the way in then that's obviously not the same thing.
>
> I am/We are aware of that.
>
>> And what is so special about octal that is_numeric() would not recognise
>> it?
>
> It has no “8” figure.
Nonetheless in PHP 5.3.23 as well as PHP 5.4.7:
$ php -r 'var_dump(is_numeric("08"));'
bool(true)
This is obviously caused by the missing special treatment of strings in
octal notation in is_numeric_string_ex().
[1] <http://lxr.php.net/xref/PHP_5_4/ext/standard/type.c>
[2] <http://lxr.php.net/xref/PHP_5_4/Zend/zend_operators.h>
--
Christoph M. Becker
|
|
|
|
| Re: bug in is_numeric [message #181461 is a reply to message #181460] |
Fri, 17 May 2013 21:45 |
Thomas 'PointedEars'
Messages: 701
Registered: October 2010
Karma: 0
|
Senior Member |
|
|
Christoph Becker wrote:
> Thomas 'PointedEars' Lahn wrote:
>> SwissCheese wrote:
>>> Isn't that what I just mentioned I did ('Looking into the source
>>> code...') above?
>>
>> I am not sure. Which source code have you been looking into?
>
> In PHP 5.4 the definition of is_numeric() is in ext/standard/type.c (~
> line 300ff)[1]. The relevant function to do the check for arguments of
> type string is is_numeric_string_ex() in Zend/zend_operators.h (~ line
> 109ff)[2]. Apparently special support for strings in binary as well as
> octal notation is missing; only strings in decimal and hexadecimal
> notation are recognized as such (strings in octal notation are treated
> as being decimal).
>
> […] in PHP 5.3.23 as well as PHP 5.4.7:
>
> $ php -r 'var_dump(is_numeric("08"));'
> bool(true)
>
> This is obviously caused by the missing special treatment of strings in
> octal notation in is_numeric_string_ex().
>
> [1] <http://lxr.php.net/xref/PHP_5_4/ext/standard/type.c>
> [2] <http://lxr.php.net/xref/PHP_5_4/Zend/zend_operators.h>
Thank you. Perhaps you should file a documentation bug (as you have
experience with that) in the hopes that this will be considered an
implementation bug by The PHP Group after all.
PointedEars
--
> If you get a bunch of authors […] that state the same "best practices"
> in any programming language, then you can bet who is wrong or right...
Not with javascript. Nonsense propagates like wildfire in this field.
-- Richard Cornford, comp.lang.javascript, 2011-11-14
|
|
|
|
| Re: bug in is_numeric [message #181463 is a reply to message #181453] |
Sat, 18 May 2013 08:28 |
Thomas 'PointedEars'
Messages: 701
Registered: October 2010
Karma: 0
|
Senior Member |
|
|
SwissCheese wrote:
> On 05/16/2013 06:33 PM, Thomas 'PointedEars' Lahn wrote:
>> SwissCheese wrote:
>>> On 05/13/2013 05:07 AM, Thomas 'PointedEars' Lahn wrote:
>>>> > is_numeric('0x11') has nothing to do with the problem at hand.
>>>> Yes, it has. Both the added “0” prefix and the omitted “.11c” suffix
>>>> make “0x11” a proper numeric (hexadecimal integer) representation as
>>>> per the PHP grammar. Which is what is_numeric() is supposed to test.
>>> is_numeric() checks to see if the first two characters are '0x' (or
>>> '0X'), but it does not add a leading '0' if the first character is an
>>> 'x' (or 'X')... nor does it simply omit the part that is not a number
>>> '.11c'. is_numeric() checks the string as passed without altering it.
>> Aside from getting a real name and learning to quote only the relevant
>> parts of what you are replying to, you want to learn to read what you
>> quote more carefully. I have not even implied that is_numeric() adds
>> anything.
>
> Aside from the fact that I'm fairly sure 'Pointed Ears' is not part
> of -your- real name,
It's “PointedEars”, stupid, without the space. And it is customary to
include the nickname in the From header field value as I did.
> maybe you would notice that my real name is in my signature.
A real name consists of first *and* last name; it belongs in the From header
field value first, and you are evading the issue of your misconception.
>>>> >> However, there appears to be an *actual* mismatch between PHP manual
>>>> >> and implementation in said PHP version as
>>>> >>
>>>> >> is_numeric('0b11001001')
>>>> >>
>>>> >> returns FALSE when according to the manual it should return TRUE
>>>> >> (binary integer literals are available since PHP 5.4.0 per the
>>>> >> manual, and they do compile and properly evaluate in tests there.
>>>
>>> Correct as per my other reply.
>>
>> It is not correct if the manual says something else, and it does. Either
>> the manual or the implementation is wrong.
>
> 'Correct' in that the documentation is wrong... as I stated in another
> reply.
No, you did not.
Score adjusted
PointedEars
--
Danny Goodman's books are out of date and teach practices that are
positively harmful for cross-browser scripting.
-- Richard Cornford, cljs, <cife6q$253$1$8300dec7(at)news(dot)demon(dot)co(dot)uk> (2004)
|
|
|
|
| Re: bug in is_numeric [message #181464 is a reply to message #181463] |
Sat, 18 May 2013 12:00 |
Norman Peelman
Messages: 126
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 05/18/2013 04:28 AM, Thomas 'PointedEars' Lahn wrote:
> SwissCheese wrote:
>
>> On 05/16/2013 06:33 PM, Thomas 'PointedEars' Lahn wrote:
>>> Aside from getting a real name and learning to quote only the relevant
>>> parts of what you are replying to, you want to learn to read what you
>>> quote more carefully. I have not even implied that is_numeric() adds
>>> anything.
>>
>> Aside from the fact that I'm fairly sure 'Pointed Ears' is not part
>> of -your- real name,
>
> It's “PointedEars”, stupid, without the space. And it is customary to
> include the nickname in the From header field value as I did.
>
....not really sure why you have decided to attack me/start name calling
but whatever.
>> maybe you would notice that my real name is in my signature.
>
> A real name consists of first *and* last name; it belongs in the From header
> field value first, and you are evading the issue of your misconception.
>
....sorry, I was not aware there were so many rules. I have yet to see an
e-mail/news-reader client that explains them while setting up a Usenet
account.
>>>> >>> However, there appears to be an *actual* mismatch between PHP manual
>>>> >>> and implementation in said PHP version as
>>>> >>>
>>>> >>> is_numeric('0b11001001')
>>>> >>>
>>>> >>> returns FALSE when according to the manual it should return TRUE
>>>> >>> (binary integer literals are available since PHP 5.4.0 per the
>>>> >>> manual, and they do compile and properly evaluate in tests there.
>>>>
>>>> Correct as per my other reply.
>>>
>>> It is not correct if the manual says something else, and it does. Either
>>> the manual or the implementation is wrong.
>>
>> 'Correct' in that the documentation is wrong... as I stated in another
>> reply.
>
> No, you did not.
>
Well, it appears to have landed in the bit-bucket as I can't find it
either. In any regard, I was agreeing with you that there is a mismatch.
>
> Score adjusted
>
> PointedEars
>
....not keeping score.
--
Norman
Registered Linux user #461062
-Have you been to www.php.net yet?-
|
|
|
|
| Re: bug in is_numeric [message #181466 is a reply to message #181464] |
Sat, 18 May 2013 12:18 |
Luuk
Messages: 329
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 18-05-2013 14:00, Norman Peelman wrote:
>> A real name consists of first *and* last name; it belongs in the From
>> header
>> field value first, and you are evading the issue of your misconception.
>>
>
> ...sorry, I was not aware there were so many rules. I have yet to see an
> e-mail/news-reader client that explains them while setting up a Usenet
> account.
It's not a 'rule'....
It maybe more polite, but that's a different discussion.....
--
Luuk
|
|
|
|
| Re: bug in is_numeric [message #181467 is a reply to message #181464] |
Sat, 18 May 2013 12:20 |
Tim Streater
Messages: 328
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
In article <kn7q8n$of0$1(at)dont-email(dot)me>,
Norman Peelman <npeelman(at)cfl(dot)rr(dot)com> wrote:
> On 05/18/2013 04:28 AM, Thomas 'PointedEars' Lahn wrote:
>> SwissCheese wrote:
>>
>>> On 05/16/2013 06:33 PM, Thomas 'PointedEars' Lahn wrote:
>
>>>> Aside from getting a real name and learning to quote only the relevant
>>>> parts of what you are replying to, you want to learn to read what you
>>>> quote more carefully. I have not even implied that is_numeric() adds
>>>> anything.
>>>
>>> Aside from the fact that I'm fairly sure 'Pointed Ears' is not part
>>> of -your- real name,
>>
>> It's “PointedEars”, stupid, without the space. And it is customary to
>> include the nickname in the From header field value as I did.
>>
>
> ...not really sure why you have decided to attack me/start name calling
> but whatever.
>
>>> maybe you would notice that my real name is in my signature.
>>
>> A real name consists of first *and* last name; it belongs in the From header
>> field value first, and you are evading the issue of your misconception.
>>
>
> ...sorry, I was not aware there were so many rules. I have yet to see an
> e-mail/news-reader client that explains them while setting up a Usenet
> account.
There aren't any rules, it's just PointyHead trying to appoint himself
as Fuhrer of this ng.
--
Tim
"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted" -- Bill of Rights 1689
|
|
|
|
| Re: bug in is_numeric [message #181468 is a reply to message #181464] |
Sat, 18 May 2013 12:47 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 5/18/2013 8:00 AM, Norman Peelman wrote:
>
> ...sorry, I was not aware there were so many rules. I have yet to see an
> e-mail/news-reader client that explains them while setting up a Usenet
> account.
>
There aren't. These are just Pointed Heads way of proving his manhood.
Most others don't care as long as you're not trolling.
But then he's well known for this in several newsgroups, not just this one.
Go ahead and use a nick if you want - and ignore Pointed Head. He's not
worth the trouble.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
|
|
| Re: bug in is_numeric [message #181470 is a reply to message #181452] |
Sat, 18 May 2013 12:51 |
Christoph Becker
Messages: 91
Registered: June 2012
Karma: 0
|
Member |
|
|
Jerry Stuckle wrote:
> No, but since it is unrelated to the OP's problem, it's nothing more
> than thread hijacking - something Pointed Head is well known for, as I
> said before.
>
> If Pointed Head wanted to bring it up, he should have started a new
> thread. Or, better yet, reported it on the PHP bugs database, since
> none of the PHP developers pay attention to this newsgroup.
Does it really matter if the issue is pointed out in this thread or in a
new thread with the subject "bug in is_numeric"? And does it matter who
files a respective bug report? After all, we all benefit from being PHP
as bug free/clearly documented as possible.
--
Christoph M. Becker
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]