FUDforum
Fast Uncompromising Discussions. FUDforum will get your users talking.
Home » Imported messages » comp.lang.php » bug in is_numeric
Show: Today's Messages :: Polls :: Message Navigator
Return to the default flat view Create a new topic Submit Reply
Re: bug in is_numeric [message #181446 is a reply to message #181341] Thu, 16 May 2013 22:28 Go to previous messageGo to previous message
SwissCheese is currently offline  SwissCheese
Messages: 17
Registered: December 2012
Karma:
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?-

Report message to a moderator

[Message index]
 
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: problem encrypting data (AES_ENCRYPT/AES_DECRYPT)
Next Topic: Debian: php fast-cgi along with mod_php
Goto Forum:
  

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ]

Current Time: Wed Nov 27 00:15:41 GMT 2024

Total time taken to generate the page: 0.03930 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.1.3.
Copyright ©2001-2023 FUDforum Bulletin Board Software