A previous bug fix[1] relied on ODBC drivers to properly count down the
`StrLen_or_IndPtr` argument for consecutive calls to `SQLGetData()`.
Apparently, not all drivers handle this correctly, so we cannot assert
they do. Instead we fall back to the old behavior for drivers which
would violate the assertion.
A test against SQLServer (which we currently use in CI) would not make
sense, since the respective drivers do not exhibit that behavior.
Instead we target the regression test especially to a MS Access
database.
Since there is apparently no way to easily create an MS Access database
programmatically, we commit a minimal empty DB which is used for the
regression test, and could also be used by other test cases.
[1] <bccca0b53aa60a62e2988c750fc73c02d109e642>
Closes GH-16587.
A common convention is to name internal C header files as `*_int.h`.
Since a couple of these are actually installed, we add comments that
this is not supposed to happen, (a) to avoid installing further
internal headers, and (b) to pave the way to fix this in the next major
PHP version.
Somewhat special is php_gmp_int.h, where "int" is meant as abbreviation
for "interface".
Another common convention is appending `_priv` or `_private`, but since
there have not been any issues regarding these headers so far, we
refrain from adding respective comments to these headers.
Anyhow, it might be a good idea to introduce some common naming
convention for such internal/private headers.
When a class (or enum) has no methods, rather than using an array that only
contains `ZEND_FE_END`, use `NULL` for the functions. The implementation of
class registration for internal classes, `do_register_internal_class()` in
zend_API.c, already skips classes where the functions are `NULL`. By removing
these unneeded arrays, we can reduce the size of the header files, while also
removing an unneeded call to zend_register_functions() for each internal class
with no extra methods.
Currently, internal classes are registered with the following code:
INIT_CLASS_ENTRY(ce, "InternalClass", class_InternalClass_methods);
class_entry = zend_register_internal_class_ex(&ce, NULL);
class_entry->ce_flags |= ...;
This has worked well so far, except if InternalClass is readonly. It is because some inheritance checks are run by zend_register_internal_class_ex before ZEND_ACC_READONLY_CLASS is added to ce_flags.
The issue is fixed by adding a zend_register_internal_class_with_flags() zend API function that stubs can use from now on. This function makes sure to add the flags before running any checks. Since the new API is not available in lower PHP versions, gen_stub.php has to keep support for the existing API for PHP 8.3 and below.
Follow-up of GH-15344 (687eb9125a)
This removes the customized error messages in PDO extensions when PDO is
not enabled (--disable-all or --disable-pdo) in favor of the default
error done by PHP_ADD_EXTENSION_DEP.
This replaces the AC_MSG_ERROR with AC_MSG_FAILURE, where appropriate.
The AC_MSG_ERROR outputs given message and exits the configure step. The
AC_MSG_FAILURE does the same but also automatically outputs additional
message "See 'config.log' for more details." which might help directing
the user where to look further.
The AC_MSG_ERROR is used for errors where current test step isn't logged
in the config.log and wouldn't make sense, and AC_MSG_FAILURE is mostly
used in cases of library checks, compilation tests, headers checked with
AC_CHECK_HEADER* and similar tests that are also logged in the
config.log.
AC_MSG_ERROR([Sanity check failed.]) output:
```
configure: error: Sanity check failed.
```
AC_MSG_FAILURE([Sanity check failed.]) output:
```
configure: error: in '/path/to/php-src':
configure: error: Sanity check failed.
See 'config.log' for more details
```
* Check for iODBC and unixODBC with pkg-config in PDO_ODBC
PDO_ODBC required that these backends had their path specified manually,
which was clumsy and contrary to how procedural ODBC checked it. This
adds a pkg-config based path to check for these backends that ignores
the 'dir' part of the flag, so i.e. --with-pdo-odbc=unixODBC should pick
it up from the correct location.
Generic and the special ibm-db2 usecase should be unaffected. The header
situation is unfortunately ugly, and has a workaround; this should also
be cleaned up.
* Move check for valid headers to after
* Use existing CFLAGS for PDO_ODBC header check
...instead of a separate funny variable. It does mean we have to save
and restore the value of CPPFLAGS, as AC_CHECK_HEADERS and friends rely
on that variable instead of CFLAGS.
Co-authored-by: Peter Kokot <peterkokot@gmail.com>
* Move PDO_ODBC_TYPE to AC_DEFINE, simplify CFLAGS handling
The variable PDO_ODBC_INCLUDE becomes redundant, as is the CFLAGS
override for PHP_NEW_EXTENSION if we call PHP_EVAL_INCLINE in the
generic case.
Co-authored-by: Peter Kokot <peterkokot@gmail.com>
* Use same variable names so evals can be combined
* Fix identation
* Suggested shell syntax cleanups
---------
Co-authored-by: Peter Kokot <peterkokot@gmail.com>
- Macro renamed to PHP_PDO_ODBC_CHECK_HEADER
- AC_DEFINE_UNQUOTED used instead of PHP_DEF_HAVE
- help texts added to CPP macro definitions
- CS synced a bit
* 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.
* Remove usage of SDWORD, replace with SQLINTEGER
Some different driver managers disagree if this should be 4 or 8 bytes
in size. SQLGetDiagRec expects this to be an SQLINTEGER, so we should
just use that explicitly instead of hoping that it's the same size.
Fixes GH-14367
* Replace SWORD with SQLSMALLINT
While this hasn't caused issues like the SQLINTEGER/SDWORD confusion
has, we should use what SQLDescrimeParam calls for, which is
SQLSMALLINT.
PDO include paths can be simplified and synced as done in other
extensions: either the project root directory or the phpincludedir (for
the system installation). The 'ext' include is automatically appended
when doing phpize build. In php-src it is only present on Windows build.
The PHP_CHECK_PDO_INCLUDES is left intact working as before and checks
if PDO headers are found.
SQL Server frequently deadlocks. Parallelization of these jobs, at least in CI,
is not worthwhile because there are enough tests to run in parallel for the few
workers available.
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
* Missing check: SQLAllocHandle() for the environment wasn't checked in
pdo_odbc_handle_factory(). Add a check similar to the other ones for
SQLAllocHandle().
* Inconsistent check: one of the SQLAllocHandle() calls wasn't checked
for SQL_SUCCESS_WITH_INFO. However, looking at the other uses and the
documentation we should probably check this as well.
Furthermore, since there was a mix of "SQLAllocHandle: reason" and
"SQLAllocHandle (reason)" in the error reporting, I made them
consistently use the first option as that seems to be the most used for
error reporting in this file.
Closes GH-10740.
If `SQLPutData()` *fails*, we should not call `SQLParamData()` again,
because that yields the confusing `HY010` (Function sequence error).
Instead we properly handle `SQLPutData()` errors.
For the given case (paramter length > column length), some drivers let
`SQLPutData()` fail, while others do not. Either behavior seems to
conform to the ODBC specification. Anyhow, we do not want to silently
truncate the given parameter, since that would break the behavior for
drivers which do not fail, but still don't simply truncate the given
parameter. So it is finally up to userland to avoid passing overlong
parameters – with this patch they at least get useful information about
the actual issue.
Closes GH-9541.
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.
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.
