Re: cvs: php4 / php.ini-dist php.ini-recommended /ext/filepro filepro.c /ext/session session.c /main main.c php_globals.h php_variables.c
php_variables.h

At 17:56 02/03/2003, Marcus Börger wrote:

At 16:38 02.03.2003, Zeev Suraski wrote:

Looks like for some reason, CLI registers $argv and $argc globals even though register_globals is off. Why's that?

CLI overwrites "register_argc_argv":

        zend_alter_ini_entry("register_argc_argv", 19, "1", 1, PHP_INI_SYSTEM, PHP_INI_STAGE_ACTIVATE);

If i add "register_long_arrays" like this

                zend_alter_ini_entry("register_long_arrays", 21, "1", 1, PHP_INI_SYSTEM, PHP_INI_STAGE_ACTIVATE);

all is fine.

Yeah, but it's really not related. The source of the problem is that CLI makes PHP register global variables even though register_globals is off. We can work around this, as far as I can tell, by using the workaround below.

So the question is if we want $argc/$argv without "register_long_arrays" !?

Anyway, if we want to keep this behavior, we probably should change the place where argv/argc are registered, and put it somewhere global, outside where _SERVER is created. If&when _SERVER is created, it will attempt to copy them. Thoughts?

That leads to "$_COMMAND" or "$_CMD".

Didn't quite understand what you mean by that...

To answer my question above: The above variable should be independant and its ini setting "register_argc_argv" should be independant from "register_long_arrays".

They have nothing to do with each other. The code currently fails because the engine doesn't expect the argc/argv globals to be required, because register_globals is off. Now, that the engine's smart enough not to process the server variables unless register_globals is on or _SERVER is being used, argc/argv are not created (they're created inside the routine that processes the server variables, which doesn't get called if register_globals is off and _SERVER is not being used). register_long_arrays really has nothing to do with this bug, you're just seeing the symptom of a bug that lies elsewhere... Zeev