Repository navigation
Build failure (incompatible pointer types, gcc-14) with PDO/iODBC #14367
Description
Description
Originally reported at https://bugs.gentoo.org/932763 but I've confirmed with php-8.3.7:
/var/tmp/portage/dev-lang/php-8.3.6/work/sapis-build/embed/ext/pdo_odbc/odbc_driver.c: In function ‘pdo_odbc_error’:
/var/tmp/portage/dev-lang/php-8.3.6/work/sapis-build/embed/ext/pdo_odbc/odbc_driver.c:88:79: error: passing argument 5 of ‘SQLGetDiagRec’ from incompatible pointer type [-Wincompatible-pointer-types]
88 | rc = SQLGetDiagRec(htype, eh, recno++, (SQLCHAR *) einfo->last_state, &einfo->last_error,
| ^~~~~~~~~~~~~~~~~~
| |
| SDWORD * {aka long int *}
In file included from /usr/include/iodbc/sqlext.h:82,
from /usr/include/iodbc/sqlucode.h:81,
from /var/tmp/portage/dev-lang/php-8.3.6/work/sapis-build/embed/ext/pdo_odbc/php_pdo_odbc_int.h:51,
from /var/tmp/portage/dev-lang/php-8.3.6/work/sapis-build/embed/ext/pdo_odbc/odbc_driver.c:29:
/usr/include/iodbc/sql.h:1006:27: note: expected ‘SQLINTEGER *’ {aka ‘int *’} but argument is of type ‘SDWORD *’ {aka ‘long int *’}
1006 | SQLINTEGER * NativeError,
| ~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~
Both unixODBC and iODBC typedef SQLINTEGER to either an int or a long depending on the host system:
- https://github.com/lurcher/unixODBC/blob/master/include/sqltypes.h#L148
- https://github.com/openlink/iODBC/blob/develop/include/sqltypes.h#L120
Apparently the two libraries make different choices on my system, because building against unixODBC still works, but in this case I don't think that's the root cause of the problem. If a SQLINTEGER can be either int or long, and if the PHP structure always has a fixed size SDWORD, there's probably a conversion or cast that should be done on the PHP side.
PHP Version
PHP 8.3.7
Operating System
No response
Activity
SakiTakamachi commentedon May 30, 2024
@orlitzky
Could you please tell me the results of the following commands?
orlitzky commentedon May 30, 2024
PHP did not successfully build so I don't think
php-configis available? A full build log was posted to the Gentoo bug however. I will include the./configurearguments below. For copy/pasting:And for readability:
If you are using an older gcc, you should still be able to trigger the error with
CFLAGS="${CFLAGS} -Werror=incompatible-pointer-types"SakiTakamachi commentedon May 30, 2024
@orlitzky
Ah, that's right. excuse me...
Hmm. This is strange.
einfo->last_erroris defined as follows.https://github.com/php/php-src/blob/ec54edb9e1cacb95f93648a838ff5540aaf9bd37/ext/pdo_odbc/php_pdo_odbc_int.h#L115C2-L115C8
If the SDWORD is loaded correctly, there should be no problem. And since this is code from 20 years ago, it doesn't mean that only master has been modified.
It's already late in Japan time, so I'll investigate further tomorrow.
orlitzky commentedon May 30, 2024
I found the problem. It's not the size of
SQLINTEGERthat is flaky, it'sSDWORD:On my machine this leads to different sizes for
SDWORD, one of which does not matchSQLINTEGER. With unixODBC they agree,and with iODBC they do not:
GCC has only recently started to consider this an error.
SakiTakamachi commentedon May 30, 2024
Ah, I see, thank you!
In this case, it looks like we just need to cast it.
NattyNarwhal commentedon May 30, 2024
I did some investigation and
last_errorhas been defined asSDWORDsince the beginning of PDO_ODBC. It's an odd choice sinceSQLGetDiagRecdefines that argument asSQLINTEGER.There's also some cases of its relative,
SWORDbeing used in PDO_ODBC as well, mostly for i.e. column types. While I think those should always be equivalent toshort, I think those should probably beSQLSMALLINTsince that's what i.e.SQLDescribeParamcall for as well.Remove usage of SDWORD, replace with SQLINTEGER
Remove usage of SDWORD, replace with SQLINTEGER
Remove use of SDWORD and SWORD in ODBC extensions (GH-14457)
orlitzky commentedon Jun 4, 2024
Thanks for the fix!