Does PHP also perform shallow copy-on-write for values passed as
parameters to functions?
";
function blah( $copy )
{
echo $copy;
}
blah( $text );
?>
Some of the guys I work with like to use: function( &$copy ) in order to
save the hypothetical storage space required to duplicate $
I agree about needing to clean up some of the other PHP ini options
first. I started creating an "uber-clean" project not long ago, with my
first goal being to get PHP into a 'known-good' state no matter what the
end-user has set up as a configuration option.
E_ALL & E_NOTICE
track_vars ON
Mike-
If you're a LAMP user, then this vi mapping might help you out ;^)
:imap ~P $GLOBALS['HTTP_POST_VARS']['']hi
...and I believe I have addressed most of your points in my previous
posting on the subject. Forgive me if you've already read it, or if it
doesn't explain my position fully.
Thanks for your responses (again), it is an unfortunate situation that
$HTTP_*_VARS must be retained for backwards compatibility until at least
the hypothetical PHPv5.0 mark. Having also read in this group that
define() does not support complicated constants, I'm guessing that it's
not currently
This is the second time in as many weeks that we have been bitten by the
fact that $_POST != $HTTP_POST_VARS; Attached is a real-world example of
why it is currently bad practice to use the _POST variables.
I cannot recommend that anyone use $_POST[..] in their scripts.
$GLOBALS['HTTP_POST_VARS'
I spoke briefly with Jan about the following (imho) mis-feature,
who recommended bringing it up on the dev-list.
http://bugs.php.net/?id=14952
I ran into the problem (as an end-user) while trying to muck
with what the user had passed in (ie: spoof GET data from
session-ized defaults if the us
