TalkPHP - Bug in PHP?/Unknown output?

TalkPHP (http://www.talkphp.com/forums.php)

- Advanced PHP Programming (http://www.talkphp.com/advanced-php-programming/)

- - Bug in PHP?/Unknown output? (http://www.talkphp.com/advanced-php-programming/4187-bug-php-unknown-output.html)

Y.P.Y

04-25-2009 09:09 AM

Bug in PHP?/Unknown output?

Hi,
This is a simple function for throwing error in a MySQL class(Private)...

PHP Code:


		
			
final private static function _Throw_Error($Str_CalledFunction= __function__)

{

return(exit('[' . $_SERVER['SERVER_SOFTWARE'] . '] [' . basename(__file__) . '] [' . (string)$Str_CalledFunction . '] [' . __line__ . '] [' . mysql_error() | -9999 . false . null . ThisIsNotAVariable . '].'));

}

Check output!

Output: yyy{|mososntiWi~{sklu]~/5.2.8] [mysql.php] [XXXXX] [219] [

OS: Redhat Linux/Windows Xp SP2
PHP: 4/5
Server: Apache 2

Salathe

04-25-2009 11:22 AM

Oh where to start.

There is absolutely no need for the return since you call exit.
Whilst they might "just work", the built-in magic constants should be uppercased: __FUNCTION__, __FILE__ and __LINE__.
What is this all about: | -9999 . false . null . ThisIsNotAVariable .. As far as I can see it serves no practical purpose (and is the cause of your "bug").
Personally, I think things would look much prettier with sprintf.

Now onto the "bug", which really isn't one. The root of the problem is that you use the "bitwise or" (|) operator which is playing around with the bits in your strings. It is basically taking the string before the | and "or"ing that with the string after it. The output will vary but given the following:

Code:

$_SERVER['SERVER_SOFTWARE'] = 'my server software';

basename(__FILE__)          = 'bug.php';

$Str_CalledFunction         = 'bug';

__LINE__                    = 3;

mysql_error()               = '';

ThisIsNotAVariable          = 'ThisIsNotAVariable';

Then the line will try to output the following expression:

Code:

'[my server software] [bug.php] [bug] [3] [' | '-9999ThisIsNotAVariable].'

The result, for this case, being:

Code:

}y9{uzw{sovuwarm}bg}o.php] [bug] [3] [

and for my local server (Apache/2.2.9 (Unix) PHP/5.3.0RC2-dev):

Code:

yyy{|mososntiWo{yibmo}ssl/2.2.9 OpenSSL/0.9.7l DAV/2 PHP/5.3.0RC2-dev mod_perl/2.0.2 Perl/v5.8.8] [bug.php] [fail] [9] [

Y.P.Y

04-25-2009 11:39 AM

But i thinking this is a bug...

Salathe

04-25-2009 11:41 AM

It is not.

Orc	04-25-2009 02:38 PM

Oh and I think you need to manage your code better, that's all jumbled into one place. :S

Wildhoney

04-25-2009 02:53 PM

What is your intention? To attempt to break PHP? I think PHP will break you before you break PHP.

Village Idiot

04-25-2009 04:03 PM

Quote:

Originally Posted by Y.P.Y (Post 23409)

But i thinking this is a bug...

It's not.

In programming, before you go yelling "bug!" you should know how it happened, why its a bug, and how it could be fixed. Otherwise you do not understand the issue and are therefore not qualified to assess if it is indeed a bug. At this point you simply do not understand the nature of the code, which may be because it one of the messiest pieces of code I've seen in a very long time. I can hardly read that.....

The reason you are getting these weird characters is because you are making bad conversions to a string. Since all data boils down to 0's and 1's, all data can be applied to all other data; you just won't get anything nice looking. I see you outputting the following:
1. Strings
2. Something typecasted to a string
3. Integers
4. Booleans (which are integers)
5. Strings with integer operations applied to them

With all that meshed into one output statement, I find it amazing you are surprised at the unreadable output.

Kalle

04-25-2009 06:02 PM

Quote:

Originally Posted by Wildhoney (Post 23415)

What is your intention? To attempt to break PHP? I think PHP will break you before you break PHP.

This calls for #46156:
http://bugs.php.net/bug.php?id=46156

As for the replies;

Salathe, __FILE__ etc. is actually not constants, they are tokens and replaced at compile time:

PHP Code:


		
			
<?php

    class A

    {

        public function b()

        {

            $this instanceof __CLASS__;

        }

    }

?>

PHP will find the following tokens here (without the whitespace):

Code:

T_OPEN_TAG

T_CLASS

T_STRING

'{'

T_PUBLIC

T_FUNCTION

T_STRING

'('

')'

'{'

T_VARIABLE

T_INSTANCEOF

--> T_CLASS_C <--

';'

'}'

'}'

T_CLOSE_TAG

Because __CLASS__ here is a special (magic) compile time constant, you don't need to instanciate A and then call b to trigger this, simply run the script and PHP will give you an E_COMPILE_ERROR (I think it is) saying T_STRING, T_VARIABLE or $ is expected.

But for the "bug" itself, it comes from the bitwise operator and how ASCII characters are used in those operations. The expression you write:

PHP Code:


		
			
'[' . $_SERVER['SERVER_SOFTWARE'] . '] [' . basename(__file__) . '] [' . (string)$Str_CalledFunction . '] [' . __line__ . '] [' . mysql_error() | -9999 . false . null . ThisIsNotAVariable . '].'

Will looks like this when all is concated before the bitwise OR operator is used:

PHP Code:


		
			
'[Apache/2.2.11 (Win32) PHP/5.3.0RC2-dev] [test.php] [] [6] [' . | . '-9999ThisIsNotAVariable]';

I'm not totally into bitwise operations and ASCII and how the 'weird' characters comes into the picture, but I'm sure it has a logical explanation =)

Salathe

04-25-2009 06:14 PM

Quote:

Originally Posted by Kalle (Post 23424)

Salathe, __FILE__ etc. is actually not constants, they are tokens and replaced at compile time:

I didn't say they were constants, I used the terminology associated with them in the manual and in common use by everyone: magic constants. I'm not entirely sure if you were correcting me, or teaching others. ::-/

Kalle

04-25-2009 06:18 PM

Quote:

Originally Posted by Salathe (Post 23426)

I know the terminology in the manual says they are constants :P, but the manual doesn't explain much about compile time stuff which can be a useful insight while talking about them here, so I guess it was teaching :)

Salathe

04-25-2009 06:44 PM

Quote:

Originally Posted by Kalle (Post 23424)

I'm not totally into bitwise operations and ASCII and how the 'weird' characters comes into the picture, but I'm sure it has a logical explanation =)

The ASCII is treated just like a sequence of bytes. The weird characters are just those which aren't "printable" (around 1/4 of ASCII characters).

For example:

Code:

Apac = 01000001 01110000 01100001 01100011

9999 = 00111001 00111001 00111001 00111001

yyy{ = 01111001 01111001 01111001 01111011  ('Apac' | '9999')

All times are GMT. The time now is 07:04 PM.