ext/odbc: There is no need to rely on ZEND_NUM_ARGS() (#16106)

Output diagnostics when SQLFetch with SQL_ERROR

These diagnostics can be useful, and if not for users, at least for the
ext/odbc maintainers. We only call `odbc_sql_error()` if the prev

Output diagnostics when SQLFetch with SQL_ERROR

These diagnostics can be useful, and if not for users, at least for the
ext/odbc maintainers. We only call `odbc_sql_error()` if the previous
`SQLFetch()` or `SQLFetchExtended()` return `SQL_ERROR`, because
otherwise the diagnostic would be unhelpful ("Failed to fetch error
message, SQL state HY000").

Note that the diagnostic is emitted as `E_WARNING` so technically this
is a small BC break.

Closes GH-15256.

show more ...

Preferably include from build dir (#13516)

* Include from build dir first

This fixes out of tree builds by ensuring that configure artifacts are included
from the build dir.

Preferably include from build dir (#13516)

* Include from build dir first

This fixes out of tree builds by ensuring that configure artifacts are included
from the build dir.

Before, out of tree builds would preferably include files from the src dir, as
the include path was defined as follows (ignoring includes from ext/ and sapi/) :

-I$(top_builddir)/main
-I$(top_srcdir)
-I$(top_builddir)/TSRM
-I$(top_builddir)/Zend
-I$(top_srcdir)/main
-I$(top_srcdir)/Zend
-I$(top_srcdir)/TSRM
-I$(top_builddir)/

As a result, an out of tree build would include configure artifacts such as
`main/php_config.h` from the src dir.

After this change, the include path is defined as follows:

-I$(top_builddir)/main
-I$(top_builddir)
-I$(top_srcdir)/main
-I$(top_srcdir)
-I$(top_builddir)/TSRM
-I$(top_builddir)/Zend
-I$(top_srcdir)/Zend
-I$(top_srcdir)/TSRM

* Fix extension include path for out of tree builds

* Include config.h with the brackets form

`#include "config.h"` searches in the directory containing the including-file
before any other include path. This can include the wrong config.h when building
out of tree and a config.h exists in the source tree.

Using `#include <config.h>` uses exclusively the include path, and gives
priority to the build dir.

show more ...

Clean-up some more headers (#14416)

Remove unused headers (such as php_ini.h for extensions that don't define INI settings)
Use more specific headers when possible

Clean-up unused headers (#14365)

* ext/mbstring.c: clean-up headers and include intrinsics

ext/odbc: Remove unused INI settings (#14399)

Add cast_object handler for objects which were recently converted from resources

Add prefix for ext/odbc persistent resource hash

In order to make sure that it doesn't accidentally clash with other resource types

Add GC_PERSISTENT_LOCAL flag for ODBC structures (#14094)

Fixes nightly builds where ZEND_RC_DEBUG is enabled

Fix casing of the ODBC namespace in error messages

Migrate ext/odbc resources to opaque objects (#12040)

Co-authored-by: Niels Dossche <7771979+nielsdos@users.noreply.github.com>

Make ext/odbc default value handling more consistent (#13910)

These changes are carved off from https://github.com/php/php-src/pull/12040/files. I noticed that there are some inconsistencies

Make ext/odbc default value handling more consistent (#13910)

These changes are carved off from https://github.com/php/php-src/pull/12040/files. I noticed that there are some inconsistencies between odbc_fetch_object()/odbc_fetch_array(), odbc_fetch_into(), as well as odbc_fetch_row(), specifically in how they handle the $row parameter. Now, I tried to align their behaviour the following way:

- I made null the default value. Previously, the default values were one of the following: -1, -1, 0, and null, respectively.
- odbc_fetch_row() has been returning false indicating there is no more rows when 0 is passed as $row. Now, a warning is also emitted in this case, because the null default value is not new, because it's available since PHP 8.0.
- When HAVE_SQL_EXTENDED_FETCH is not defined, the $row parameter is always ignored. Previously, some of the functions didn't accept it at all. Now a warning is emitted if the feature is not supported, but the parameter has any meaningful value (is greater than or equal to 1).

show more ...

Convert odbc_bindcols() function to void (#13900)

Get rid of non-exposed solid_fetch_prev() function

Somehow it wasn't exposed to userland.

Fix ZTS crashes with persistent resources in modules (#13381)

On shutdown in ZTS the following happens:
- https://github.com/php/php-src/blob/master/Zend/zend.c#L1124-L1125
gets ex

Fix ZTS crashes with persistent resources in modules (#13381)

On shutdown in ZTS the following happens:
- https://github.com/php/php-src/blob/master/Zend/zend.c#L1124-L1125
gets executed. This destroys global persistent resources and destroys
the modules. Furthermore, the modules are unloaded too.
- Further down, `ts_free_id(executor_globals_id)` gets executed, which
calls `executor_globals_dtor`. This function destroys persistent
resources for each thread.

Notice that in the last step, the modules that the persistent resource
belong to may already have been destroyed. This means that accessing
globals will cause a crash (I previously fixed this with ifdef magic),
or when the module is dynamically loaded we'll try jumping to a
destructor that is no longer loaded in memory. These scenarios cause
crashes.

It's not possible to move the `ts_free_id` call upwards, because that
may break assumptions of callers, and furthermore this would deallocate
the executor globals structure, which means that any access to those
will cause a segfault.

This patch adds a new API to the TSRM that allows running a callback on
a certain resource type. We use this API to destroy the persistent
resources in all threads prior to the module destruction, and keep the
rest of the resource dtor intact.

I verified this fix on Apache with postgres, both dynamically and
statically.

Fixes GH-12974.

show more ...

Fix GH-12974: Apache crashes on shutdown when using pg_pconnect()

On ZTS, the global variables are stored in dynamically allocated memory.
When the module gets shut down this memory is r

Fix GH-12974: Apache crashes on shutdown when using pg_pconnect()

On ZTS, the global variables are stored in dynamically allocated memory.
When the module gets shut down this memory is released. After the module
is shut down, only then are the persistent resources cleared. Normally
this isn't an issue, but pgsql and odbc refer to the globals to modify
some counters, after the globals have been freed.
Fix this by guarding the modification.

Closes GH-13032.

show more ...

ext/pgsql: pgsql.allow_persistent, no need to use such large type for boolean state.

also ext/odbc, simplifying odd comparison with non persistent connections.

Close GH-12976

Fix GH-12296: [odbc] [pdo_odbc] Optimized odbc connection string creating (#12306)

Declare and initialize on one line

changed to use php_memnistr

store strlen(db) in a vari

Fix GH-12296: [odbc] [pdo_odbc] Optimized odbc connection string creating (#12306)

Declare and initialize on one line

changed to use php_memnistr

store strlen(db) in a variable

Added a semicolon to the end of dsn.

If there is a semicolon at the end of the original dsn, it will be duplicated, so it will be removed.

Add condition when authentication information is null

show more ...

Fix persistent procedural ODBC connections not getting closed

Like oci8, procedural ODBC uses an apply function on the hash list to
enumerate persistent connections and close the specifi

Fix persistent procedural ODBC connections not getting closed

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>

show more ...

Fix memory leak with failed SQLPrepare

Closes GH-12095

Signed-off-by: George Peter Banyard <girgias@php.net>

Use correct format specifier

Make the $enable parameter of odbc_autocommit() nullable (#11909)

Co-authored-by: George Peter Banyard <girgias@php.net>

Update INI validator and displayers depending on INI type

Closes GH-9451

Use php_info_print_table_header for actual column headers only (#9485)

Using php_info_print_table_header() for "Foo: bar" looks odd and out of place,
because the whole line is colored. I

Use php_info_print_table_header for actual column headers only (#9485)

Using php_info_print_table_header() for "Foo: bar" looks odd and out of place,
because the whole line is colored. It is also questionable from a HTML
semantics point of view, because it does not described the columns that follow.

The use of this across extensions is inconsistent. It was part of the skeleton,
but ext/date or ext/json already use a regular row.

show more ...

Fix GH-9347: Current ODBC liveness checks may be inadequate

We implement SQL_ATTR_CONNECTION_DEAD for ODBC and PDO_ODBC.

This is semantically appropriate and should be used whenever

Fix GH-9347: Current ODBC liveness checks may be inadequate

We implement SQL_ATTR_CONNECTION_DEAD for ODBC and PDO_ODBC.

This is semantically appropriate and should be used whenever the
driver supports it. In the event that it fails or says the connection
isn't dead (which may be inaccurate in some cases), try the old
heuristic.

Closes GH-9353.

show more ...