In this test file, the free_obj handler is called with a refcount of 2,
caused by the fact we do a GC_ADDREF() to increase its refcount while
its refcount is still 1 because the Foo object hasn't been destroyed yet
(due to the cycle caused by the sqlite function callback).
Solve this by introducing a get_gc handler.
Closes GH-11881.
The type will always be XML_ATTRIBUTE_NODE by construction via
php_dom_create_object, no need to check the type. Use an assertion
instead. This simplifies code and reasoning about error conditions.
...So conditionally including code which uses __builtin_usub_overflow
(for performance) if the macro is defined is not correct. We also need
to check if the macro is defined as a non-zero value.
Apparently this broke the build for a user whose C compiler is GCC
4.9.4. Sorry, user! That was my fault!
Thanks to Jakub Zelenka for reporting the issue.
`ext/odbc/tests/config.inc` overrides the INIs used for the ODBC driver
manager pointlessly. It's not pointing to some custom PHP test suite
specific one, but the system one in `/etc/odbc(inst).ini`. Which
doesn't necessarily exist, on i.e. NixOS, MacPorts, etc.
Closes GH-12133
Signed-off-by: George Peter Banyard <girgias@php.net>
Like oci8, procedural ODBC uses an apply function on the hash list to
enumerate persistent connections and close the specific one. However,
this function take zvals, not resources. However, it was getting casted
as such, causing it to interpret the pointer incorrectly. This could
have caused other issues, but mostly manifested as failing to close the
connection even fi it matched.
The function now takes a zval and gets the resource from that. In
addition, it also removes the cast of the function pointer and moves
casting to the function body, to avoid possible confusion like this in
refactors again. It also cleans up style and uses constants in the
function body.
Closes GH-12132
Signed-off-by: George Peter Banyard <girgias@php.net>
It looks like sqlite3_step can vary quite drastically from one request to the
next. This seems to be caused by more or fewer calls to sqlite3VdbeSorterWrite.
It would be great if we could find a way to make execution of this function more
consistent, but at this point I don't know how.
Closes GH-12130
There were 4 different reports of this breaking behavior. This is higher than I
expected. This bug fix may still be desirable, but should be discussed on the
list beforehand.
Closes GH-12127
Passing NULL as the pointer to intl_error* will use the global error stack.
This is what we need to do instead of pushing it onto the temporary format object that is released.
