sql.c opened with
#ifndef SQLLEN
#define SQLLEN SQLINTEGER
#endif
meant as a fallback for header sets that predate SQLLEN. SQLLEN is a
typedef in every modern set, and the preprocessor cannot see a typedef,
so the test was always true: the define fired everywhere and quietly
turned the real 64 bit type into a 32 bit one for the whole file - the
indicator fields of struct sql_col_bind_data included, which is why
calls that read correctly still failed.
That produced 20 errors under gcc 14 (SQLBindCol argument 6, SQLRowCount
argument 2, SQLGetData argument 6, SQLBindParameter argument 10,
SQLDescribeCol argument 7, which wants SQLULEN *), reported by a user
building on AlmaLinux 10. gcc 14 turns -Wincompatible-pointer-types into
an error; before that this was a warning nobody was reading, over a real
defect: on any LP64 platform the driver was handing 4 byte objects to
functions that write 8 bytes into them, including a heap allocation of
sizeof(SQLINTEGER) for a value ODBC writes a SQLLEN into.
The fallback now keys off A4GL_ODBC_HEADERS_LACK_SQLLEN, set only by the
SQLITEODBC branch that includes the bundled tools/odbctest/incl headers -
the one set that genuinely has no SQLLEN. It cannot be detected any other
way: ODBCVER is no help, since those same bundled headers announce
0x0350. unixODBC does define SQLLEN as a macro, but only in the cases
where it is SQLINTEGER anyway, so the !defined(SQLLEN) half is kept.
It moved into a4gl_lib_sql_odbc_int.h because the prototypes there use
these types, so every file including that header needs them.
The declarations that feed ODBC out parameters are corrected to
SQLLEN/SQLULEN, and A4GL_display_size takes SQLULEN to match
SQLDescribeCol.
Verified by compiling sql.c against all three header sets: unixODBC
2.3.12 goes from 20 errors to none, iODBC builds clean, and the
SQLITEODBC path still builds with the fallback active. sqlite3odbc.c and
sqliteodbc.c are unchanged by this - they fail the same way before and
after, wanting a system <sql.h> on the include path.
