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 #181353 is a reply to message #181347] Mon, 13 May 2013 14:57 Go to previous messageGo to previous message
Thomas 'PointedEars' is currently offline  Thomas 'PointedEars'
Messages: 701
Registered: October 2010
Karma:
Senior Member
Jerry Stuckle wrote:

> On 5/13/2013 5:07 AM, Thomas 'PointedEars' Lahn wrote:
>> Jerry Stuckle wrote:
>>> On 5/12/2013 7:27 PM, Thomas 'PointedEars' Lahn wrote:
>>>> 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 statement was wrong in ANY context. […]

No, it was and is not.

> You would have been much better off just admitting your statement was
> wrong and moving on. But your ego doesn't allow that.

It has nothing to do with ego to explain to you why you misinterpret my
statement. It has to do with being honest, a concept that you appear to
have problems with.

>>>> > 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.
>
> Nope. The rest of your argument was based on a false premise.

It was not. Your turn.

>>>> > 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().
>
> Unlike you, I understand EXACTLY what is_numeric() does.

How did you get the idea that I would not understand what it does? I have
explained in great detail what it does. Your problem is that you
continuously misinterpret my statements. You should read them more
carefully.

> And I also understand that 'x11' can NOT be a hexadecimal representation
> in PHP,

Which I have already said *thrice* now.

> and a '.' within a quoted string is NEVER a concatenation character.

I am well aware of that, too. However, you are not aware that I was not
debating that fact, or claiming the opposite. I was discussing the reasons
why the argument to is_numeric() is not – cannot be – considered 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.
>
> Nope, it is NOT a standalone identifier, and it is NOT a constant. […]

Apparently you have a problem understanding the concept of a hypothetical
argument as well. I was explaining how the string *content* *would be*
parsed *if* it *would be* used verbatim in PHP code, which explains *why* it
cannot be considered numeric.

> Also, the source code was NOT ambiguous.

Again, the string *content* *would be* ambiguous *if* used *verbatim* in PHP
code, in particular the identifier *would* *make* the resulting source code
ambiguous (*assuming* it compiled).

> And defining a constant would NOT change the meaning; […]

Yes, it would. _Declaring_ a constant with the identifier

x11

would change the evaluation value of the *standalone* expression

x11

to the string representation of the value of the constant with that
identifier, instead of the string value created from the identifier's
characters. For example:

$ php -r 'echo x11 . "\n";'
PHP Notice: Use of undefined constant x11 - assumed 'x11' in Command line
code on line 1
PHP Stack trace:
PHP 1. {main}() Command line code:0
x11

$ php -r 'define("x11", 42); echo x11 . "\n";'
42

Do you see the “assumed 'x11'” in the Notice?

>> This is important because if a sequence of characters is potentially a
>> constant identifier, it cannot be a numeric literal at the same time.
>
> Nope, a constant identifier is NOT replaced within a quoted string.

I said “*potentially* a constant identifier”. That is (AISB), *if* such a
constant would *not* be declared, it *would be* replaced as I described.
The PHP output I already posted *clearly* shows that. Here it is again:

| $ php -r 'echo x11 . x11c;'
| PHP Notice: Use of undefined constant x11 - assumed 'x11' in Command
| line code on line 1
| PHP Stack trace:
| PHP 1. {main}() Command line code:0
| PHP Notice: Use of undefined constant x11c - assumed 'x11c' in Command
| line code on line 1
| PHP Stack trace:
| PHP 1. {main}() Command line code:0
| x11x11c
^^^^^^^

| $ php -v
| PHP 5.4.4-15 (cli) (built: Mar 22 2013 15:41:03)
| Copyright (c) 1997-2012 The PHP Group
| Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies
| with XCache v3.0.1, Copyright (c) 2005-2013, by mOo
| with Xdebug v2.2.1, Copyright (c) 2002-2012, by Derick Rethans
| with XCache Optimizer v3.0.1, Copyright (c) 2005-2013, by mOo
| with XCache Cacher v3.0.1, Copyright (c) 2005-2013, by mOo
| with XCache Coverager v3.0.1, Copyright (c) 2005-2013, by mOo

How can you deny that the concatenation

x11 . x11c

is evaluated to

'x11' . 'x11c'

and thus to

'x11x11c'

when neither identifier is that of a constant?

>>>> 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.
>
> It is not a constant like you indicate.

I have not indicated that it is a constant. I have said repeatedly now that
*if* the string value *was* used verbatim in PHP code, it *would be*
considered a concatenation operation with the first argument being
considered a constant identifier. An identifier that *would be* resolved as
I said if *no* such constant *would be* declared.

>>>> 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.
>>> 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.
>
> Again, completely unrelated to what the OP asked. […]

A difference between the documentation and the implementation of
is_numeric() is _not_ at all unrelated to the subject of “bug in
is_numeric”.

> […]
> No wonder you're so well known as a troll in so many newsgroups.

It takes one to know one.


PointedEars
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f806at$ail$1$8300dec7(at)news(dot)demon(dot)co(dot)uk>

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: Tue Nov 26 23:59:20 GMT 2024

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

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