Fix very nasty bug - session cookie kills one of the cookies
set before it on certain non-Apache SAPIs.
# for example, this code:
# <?
# setcookie("abc", 1);
# setcookie("def", 2);
# session_start();
# ?>
# would output only 'def' cookie on CGI and ISAPI
It strikes me as awkward that a Zend API user needs to take care of
doing the engine's reference counting.
This fixes a memory overrun in a testcase. All ZEND_SET_* calls
should be correct now.
session_register("c");
unset($c);
$c = time();
If a user unsets a global session variable, it is not a reference
to a $_SESSION slot anymore.
During serialization, PHP 4.2 will not find the respective entry in
$_SESSION and fall back to the global sym table.
completely in PS(http_session_vars). This avoids bugs which are caused
by a lack of synchronization between the two hashes. We also don't need
to worry about prioritizing one of them.
Add session.bug_compat_42 and session.bug_compat_warn which are enabled
by default. The logic behind bug_compat_42:
IF bug_compat_42 is on, and
IF register_globals is off, and
IF any value of $_SESSION["key"] is NULL, and
IF there is a global variable $key, then
$_SESSION["key"] is set to $key.
The extension emits this warning once per script, unless told otherwise.
"Your script possibly relies on a session side-effect which existed until
PHP 4.2.3. Please be advised that the session extension does not consider
global variables as a source of data, unless register_globals is enabled.
You can disable this functionality and this warning by setting
session.bug_compat_42 or session.bug_compat_warn.
on the state of $_SESSION/$HTTP_SESSION_VARS. It does not look up
symbols in the global symbol table anymore.
This was achieved by actually planting references between every
$_SESSION["x"] and $x, not only when restoring a session, but also
when registering a session variable (in a register_globals=1 context).
Upon registering a new variable, this memory leak continues to show
up, regardless of register_globals.
ext/session/session.c(272) : Freeing 0x0818F01C (12 bytes), script=test
Obviously, the newly allocated empty zval is not properly freed. If anyone
has any idea on how to fix that, please step forward.
