Fix GH-13119 (#13125)

Fixed an issue where pdo_firebird float and double type values were wrong.

Changed from using `%F` format with `zend_strpprintf` to using `%H` format with

Fix GH-13119 (#13125)

Fixed an issue where pdo_firebird float and double type values were wrong.

Changed from using `%F` format with `zend_strpprintf` to using `%H` format with
`zend_strpprintf_unchecked`.

Fixes GH-13119
Closes GH-13125

show more ...

Implement PDO driver-specific subclasses

RFC: https://wiki.php.net/rfc/pdo_driver_specific_subclasses
Closes GH-12804

Co-Authored-By: Danack <Danack@basereality.com>

Enable `pdo-firebird` nightly testing (#12699)

* Enable `pdo-firebird` Testing in Nightly

* fix(ext/pdo_firebird/tests): dont detect memory leak

* fix(ext/pdo_firebird): me

Enable `pdo-firebird` nightly testing (#12699)

* Enable `pdo-firebird` Testing in Nightly

* fix(ext/pdo_firebird/tests): dont detect memory leak

* fix(ext/pdo_firebird): memory alignment error

show more ...

Parallelize pdo tests (dblib, firebird, oci, odbc, pgsql) (#12395)

Co-authored-by: George Peter Banyard <girgias@php.net>
Co-authored-by: Jorg Adam Sowa <jorg.sowa@gmail.com>

Fix test for GH-10908

It turns out that the version of Firebird influences the test in terms
of supported data types. On Windows on 8.2 we seem to be using a
different version than o

Fix test for GH-10908

It turns out that the version of Firebird influences the test in terms
of supported data types. On Windows on 8.2 we seem to be using a
different version than on 8.1. Fix it by amending the test.
The core issue is still tested in the test, it's just that not all
datatypes are tested anymore (which isn't strictly necessary anyway).

show more ...

Fix GH-10908: Bus error with PDO Firebird on RPI with 64 bit kernel and 32 bit userland

The alignment of sqldata is in most cases only the basic alignment,
so the code type-puns it to a

Fix GH-10908: Bus error with PDO Firebird on RPI with 64 bit kernel and 32 bit userland

The alignment of sqldata is in most cases only the basic alignment,
so the code type-puns it to a larger type, it *can* crash due to the
misaligned access. This is only an issue for types > 4 bytes because
every sensible system requires an alignment of at least 4 bytes for
allocated data.

Even though this patch uses memcpy, the compiler is smart enough to
optimise it to something more efficient, especially on x86.
This is just the usual approach to solve these alignment problems.

Actually, unaligned memory access is undefined behaviour, so even on x86
platforms, where the bug doesn't cause a crash, this can be problematic.
Furthermore, even though the issue talks about a 64-bit kernel and
32-bit userspace, this doesn't necessarily need to be the case to
trigger this crash.

Test was Co-authored-by: rvk01

Closes GH-10920.

show more ...