The SitePoint Forums have moved.

You can now find them here.
This forum is now closed to new posts, but you can browse existing content.
You can find out more information about the move and how to open a new account (if necessary) here.
If you get stuck you can get support by emailing forums@sitepoint.com

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

"marginally" definitely means "marginally" in this case.
We're talking thousands of variable replacements (double quoted) before you'll notice ANY performace decrease, but you are correct, you do get some miniscule amount of gain from breaking out of quotes to substitute.

Security Factors

P.S. I did mention that it was only useful for those beginning to code, or high traffic/large sites, yes? marginal may not show up much in benchmarks, and may not be needed on personal websites, but sometimes every little bit helps - it's not do or die, just a tip

anyway...

one thing I almost forgot - everyone who writes php should read this - yeah I know, those of you who have been coding php forever are so sick of the document, but it's a great piece for beginning coders who often don't think about security

"These comparison operators work based on the context in which they are being used. So if you want to compare two strings, but they both happen to be valid numeric values, you're in line to get burned. The PHP way to compare two strings safely is to use strcmp(). "

I think that explains it pretty well, better than I could try...sometimes the words just don't come out right...

strcmp is binary safe
so "" == 0 is true
strcmp("",0) != 0
strcmp returns 0 for = 1 or -1 for 1=
You can get a lot of the same effect from === which compares type as well as value - but thats not always what you want because you could have problems with casting...

I guess after contemplation, wouldn't say its better to always use it, but maybe i would say always use it for something like comparing a password. Or anywhere you have mixed type values as strings, php and that loose typecasting and all. I suppose most of the time == or === is good enough. Probably faster...anyone want to do benchmarks on it?

o'reilly has a bit on it here....I just sacrifice the speed for the strcmp() always because I'm obsessive about things like security, and I don't want things sneaking in....

anyway: yes, str_replace will take an array, but I leave them seperately - I don't always strip out everything, like extra spaces and all,...and there's a typo in that...sorry...that's what happens when you cut and paste from the wrong cvs file (smacks self...) I fixed it...

Obviously, there are a few extra "cycles" spent on finding offsets for variable length data (for that matter, you have to compute offsets for fixed length data too), but probably such a small difference, it may not be measurable for most cases. Also, if you are able to improve the cache hit ratio (and/or reduce cache searches) by using fewer pages to store your data, wouldn't that more than offset the "cost" of finding variable length columns on the row?

Alright, I answered the wrong question so now I'm going back and hopefully posting something more useful.

You can still use $_SERVER style arrays even if register globals is on. So, simply ignoring registered globals can remove any problem you may have.

Problems from register globals come when you go to access $is_logged_in and little does your application know that it is being provided by $_GET['is_logged_in] (relatively insecure) rather than $_SESSION['is_logged_in'] (relatively secure).

So yes, there is an equivalent way to turn off register globals with PHP... just don't use them! Use $_SESSION['is_logged_in'] instead of the registered $is_logged_in and so on throughout your scripts.

EDIT:
This should wipe out any variables gloabally registered by the user while leaving the $_GET, $_POST and $_COOKIE arrays in tact.

Originally posted by samsm So yes, there is an equivalent way to turn off register globals with PHP... just don't use them! Use $_SESSION['is_logged_in'] instead of the registered $is_logged_in and so on throughout your scripts.

Well OK, that's what I already try to do . But I just wanted the maximum security anyways, even though I can't edit my PHP config file .

Hate waiting for pages or having your views wait? Want to reduce server load and increase page load time on EVERY page? well here is how!
Use ob_start("ob_gzhandler");! Here is an example that will compress the whole page and send it to the users browser and then the user will decode it automaticly!To get this to work properly, you have to compile PHP with "--with-zlib". Have fun with your new faster webpage

Originally posted by scoates "marginally" definitely means "marginally" in this case.
We're talking thousands of variable replacements (double quoted) before you'll notice ANY performace decrease, but you are correct, you do get some miniscule amount of gain from breaking out of quotes to substitute.

The fraction of a second may not count towards much in this case, but I still prefer the "faster" method for easier readability in color-coded editors. My editor makes any "raw" written variables stick out like a sore thumb for easy pickin, but blends them in when they're contained inside double quotes. Even the color-coded PHP on this board demonstrates what I mean:

I don't know if any editors highlight all PHP variables regardless of where they are... but if any such editor exists, I haven't seen one yet. In the meantime, it's nice to know the highlighted concantenation method not only works fine, but is a fraction of a second faster.

Why is this faster? Unlike C/C++, Java (etc), PHP is an interpretted language and isn't compiled down to machine language. So if you call a function inside a loop declaration, PHP will call that function every time it iterates though the loop.

Some extra things I forgot to mention

With regard to the whole "global vars are evil arguement," I would agree to a certain point.

For things such as "$is_logged_in," then yes, I agree that global vars are evil. On the other hand, if you look at phpBB's code, the use global vars for internal variables such as "global $db." In this case, $db is a database abstraction layer that that entire project uses. For example:

PHP Code:

/* simply authenticating users with plain text is bad in my opinion, but this is just an example*/
function auth_user(&$username, &$password)
{
global $db;

$query = "SELECT blah, blah.....";

$result = $db->sql_query($query);

$auth_array = $db->sql_fetchrow($result);

/* more code to process the results, but not important to this example */
}

For something like this, the $db class is used throughout the script, and it's easier than having to constantly pass the $db class to a function. Apparently there are problems with passing objects to a function, and using global vars in this way can help augment that.

Associative Array Interpolation in Strings

PHP Code:

echo $array['key']; // is better than

echo $array[key];

However, if you try to use $array['key'] in a double quotes echo, it won't work. What you have to do is this:

PHP Code:

echo "This is my var in the array [COLOR=red]{[/COLOR]$array['key'][COLOR=red]}[/COLOR].";

The braces help the parser distinguish the quotes between the brackets, i.e. [].

I think the official word from Zend (et al) is that you should abandon the use of double-quotes since the process to find variables in the quotes is quite costly. Not to mention it craps out quite soon (you can run benchmarks and it will eventually kill PHP).

For things such as "$is_logged_in," then yes, I agree that global vars are evil. On the other hand, if you look at phpBB's code, the use global vars for internal variables such as "global $db." In this case, $db is a database abstraction layer that that entire project uses.

So you're saying in some cases it's okay to use globals. Well, it's not (IMHO). The fact that a program uses globals can never be rectified by the reason for using them, as far as I'm concerned. So in this case I'd say: phpBB has a design problem, because it has to have at least one global variable to work properly...

Originally posted by MattR
I think the official word from Zend (et al) is that you should abandon the use of double-quotes since the process to find variables in the quotes is quite costly. Not to mention it craps out quite soon (you can run benchmarks and it will eventually kill PHP).