This piece of code seems to retain compatibility with some windows
versions before 2000. Today it's not relevant anymore and only
produces a warning C4273 because of the conflicting prototype. In
VC9 the declaration is present in winbase.h:4142, but available
is it already in winxp. Here's the doc link
http://msdn.microsoft.com/en-us/library/windows/desktop/ms680345(v=vs.85).aspx
* PHP-5.5:
stop warnings from unused opcode map
- BFN
- Fixed bug #66311 (Stack smashing protection kills PDO/ODBC queries) patch by: michael at orlitzky dot com
Included new .c file in build too
Fixed little typo in zend_vm_gen.php
Moved to new file, killing a lot of warnings
That way extensions etc. don't have to maintain their own lists anymore.
Also as phpdbg is included and needs such a map, it'd be counterproductive to need to change two things on every new opcode.
When Wincache or APC are installed, the resource IDs are not the same.
This is because Wincache takes a few resource objects for itself. As a
result, these tests become false positives.
On Windows boxes, the microtime precision is not granular enough
to reliably register a difference if two calls to uniqid() are made
concurrently. This is a fix to the uniqid() test to avoid the false
positive when run on Windows machines. Also, added a test to exercise
the 'more_entropy' variant of uniqid().
When Wincache or APC are installed, the resource IDs are not the same.
This is because Wincache takes a few resource objects for itself. As a
result, these tests become false positives.
On Windows boxes, the microtime precision is not granular enough
to reliably register a difference if two calls to uniqid() are made
concurrently. This is a fix to the uniqid() test to avoid the false
positive when run on Windows machines. Also, added a test to exercise
the 'more_entropy' variant of uniqid().
# For THTTPD:
# The code that uses a call to this function is for older versions of PHP anyway so its not covered
# For Zend OpCache:
# Added a new define for 5.6 and wrapped the code around that so its still compatible with older version
Functions registered using zend_register_functions instead of zend_module_entry.functions are not seen on reflection.
Ex: additional_functions from api_module_entry.
Ex: in CLI, dl, cli_set_process_title and cli_get_process_title
Note:
- also affects functions overrided in extension
(should be be reported in extension, where overrided, not in original extension)
- also allow extension to call zend_register_functions for various list
(instead of having a single bug list)
The 'result' argument of fast_add_function() may alias with either
of its operands (or both). Take care not to write to 'result' before
reading op1 and op2.
* PHP-5.6:
Fixed bug #66252 (Problems in AST evaluation invalidating valid parent:: reference. Constant expessions have to be evaluated in context of defining class).
The 'result' argument of fast_add_function() may alias with either
of its operands (or both). Take care not to write to 'result' before
reading op1 and op2.
I'm not exactly sure whether this is the right way to fix it. The
question is whether Generator::throw() on a newborn generator (i.e.
a generator that is not yet at yield expression) should first advance to
the first yield and throw the exception there or whether it should
instead throw the exception in the caller's context.
The old behavior was to throw it at the start of the function (i.e.
the very first opcode), which causes issues like the one in #65764.
Effectively it's impossible to properly handle the exceptions in this
case.
For now I choose the variant where the generator advances to the
first yield before throwing, as that's consistent with how all other
methods on the Generator object currently behave. This does not
necessarily match the behavior in other languages, e.g. Python would throw
the exception in the caller's context. But then our send() method already
has this kind of deviation, so it stays internally consistent at least.
All code dealing with unfinished execution cleanup is now in a separate
function (previously most of it was run even when execution was properly
finished.
Furthermore some code dealing with unclean shutdowns has been removed,
which is no longer necessary, because we no longer try to clean up in
this case.
