Aubit 4GL SVN-Code

odbc: stop redefining SQLLEN to a 32 bit type

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.

tools/misql: link with 4glpc, not 4glc

misql compiles each module to a .ao and then links the set of them. Both
steps went through ${FGLPCEXEC}, which resolves to bin/4glc here -
FGLPC_NAME in Makefile-common.in is 4glc, and the 4glpc spelling next to
it is commented out.

Driving 4glc directly to link .ao files leaves the library link line off,
so misql.4ae failed with undefined references to A4GL_set_status,
A4GL_setnull, A4GLSTK_pushFunction_v2 and the rest of libaubit4gl.
adbload gets away with the same variable only because it compiles and
links a .4gl in one step.

Both rules now use "aubit 4glpc", the documented way to drive the
compiler, which does add the link line. Verified from scratch with every
.ao and .4ae deleted first: misql.4ae builds and ldd reports
libaubit4gl.so.1 where it previously resolved nothing.

Masked on any tree built before now, because a stale misql.4ae satisfies
the target and "make clean" does not remove it. It only appears on a
fresh checkout, like the adbload breakage in r13113.

FGLPCEXEC itself is left alone: other makefiles use it and work, so what
it should point at is a bigger question than this fix.

Fix tools/adbload under gcc 14

Three errors, all of them things gcc used to warn about and now rejects
(implicit-function-declaration and int-conversion are errors in gcc 14).

1. A4GL_init_session, A4GL_init_session_with_sqltype and A4GL_set_conn
moved from a4gl_sql.h into a4gl_incl_4gldef.h.

The C generator emits calls to all three (compile_c_sql.c, for
CONNECT TO and SET CONNECTION), but a4gl_sql.h is deliberately kept
out of the generated-code include path - it is not copied by a make
install, and a4gl_4gl_callable.h says so. So every generated module
that opens a session got an implicit declaration. Declarations shared
by both include paths belong in a4gl_incl_4gldef.h, which is what
this does; they are removed from a4gl_sql.h rather than duplicated,
so -Wredundant-decls stays quiet on the library path. Signatures
checked against sql_common.c, not against the old header.

A4GL_close_session and A4GL_set_dialect are left where they are -
nothing generates calls to those.

2. adbload.4gl assigned a FILE * straight into a 4GL INTEGER inside a
CODE block. A 4GL INTEGER is a long, so it needs the cast that the
commented-out line right below it already had; readoneline() casts
the value straight back with (FILE *).

Verified by deleting every generated .4ae/.c under tools and compilers -
74 of them - and rebuilding: all regenerate with no errors. Worth
knowing that a plain "make clean" does not remove them, so a tree that
has been built before hides this entirely; it only shows up on a fresh
one, which is why it reached a user first.

Stop writing database credentials into aubitrc

A4GL_SQLUID and A4GL_SQLPWD are no longer written to aubitrc, and
configure no longer has --with-sqluid/--with-sqlpwd to fill them in.

A database password does not belong in a file that ships with the
product and is read by every program that starts. The setting itself is
unchanged and still works - the driver reads SQLUID/SQLPWD from the
environment, and a site that wants them in a file can add the lines to
an aubitrc of its own. aubitrc.in keeps them as commented examples so
the names are still discoverable.

This also removes the last way for the placeholder bug to recur: until
r13108 the unsubstituted @SQLUID@ reached the installed aubitrc as a
literal and was handed to the server as a user name, failing every
connection with -951. Nothing is substituted there now because nothing
is written there.

Partly reverts the configure side of r13108. The other substitutions it
added (aubitdir_src, CINT, CINTSYSDIR, MINGW_ROOTDIR,
WARN_LD_LIBRARY_REASON) are still needed and are untouched.

Note for upgrades: an aubitrc already on disk keeps whatever it has, and
can no longer be overridden by a later-read file that simply omits the
setting. Anyone who has @SQLUID@ in an installed aubitrc needs that file
regenerated or the two lines removed - rebuilding alone will not do it.

configure regenerated with autoreconf.

Makefile: don't ship the packaging machine's settings in a source tarball

etc/aubitrc and friends are generated by configure and are not in SVN,
but the tar target only ran clean.all and clean.tools, neither of which
removes them - so whatever the packaging machine had ended up in the
tarball. That file hard-codes absolute paths:

AUBITDIR=/home/aubit4gl/aubit4glsrc
AUBITETC=/home/aubit4gl/aubit4glbin/etc/aubit4gl
A4GL_SQLCNVPATH=/home/aubit4gl/aubit4glsrc/etc/convertsql

so a tarball user starts out pointed at directories that exist only on
the machine the release was rolled on, and has to work out for himself
that re-running configure is what fixes it. It also carries whatever
configure substituted in, which is how a tarball built between the
configure rewrite and r13108 hands out A4GL_SQLUID=@SQLUID@ and breaks
every database connection with -951.

tar now depends on clean.settings, which removes exactly those four
generated files. Note it is deliberately not clean.configure: that was
tried before and backed out (see func_make_source_tarball in
bin/aubitbuild.sh) because it removes the makefiles the target is
running from. clean.settings does not touch them.

A source tarball therefore no longer contains etc/aubitrc until
./configure has been run, which is the usual contract for one.

esqlc: say why strip() leaves the first character alone

Comment only, no change in behaviour.

strip() stops at str[0] rather than clearing it, which reads like an
off-by-one. It is deliberate: an empty field in an unload file means
NULL, so a column holding an empty or all-blank CHAR has to keep one
space to come back from LOAD as a value rather than a null.

Nothing said so, and the bound is an easy thing to "tidy up" while
working on unload formatting.

esqlc: strip the padding from INT8/SERIAL8 values on UNLOAD

ifx_int8toasc() writes the digits left justified and blank pads out to
the length it is given, without terminating. The unload path passed the
full buffer and then only skipped blanks on the *left*, which there
never are, so every INT8 and SERIAL8 value was written to the file
padded to the width of the buffer:

0 |
9223372036854775807 |

rather than

0|
9223372036854775807|

The values themselves were right, but the files do not match what
Informix produces, and the padding is carried into anything that reads
them by column position.

Now calls strip() on the buffer first, which is exactly what the
DECIMAL case already does with dectoasc() output for the same reason.
The left hand skip is kept as a guard in case a future version right
justifies, with a comment saying so rather than asserting the padding
is on that side.

Verified by unloading INT8 and SERIAL8 columns and loading the file
back: all columns compare equal after the round trip, and DECIMAL and
CHAR fields in the same file are unaffected.

configure: substitute SQLUID/SQLPWD again, and the other aubitrc placeholders

etc/aubitrc.in carries @SQLUID@ and @SQLPWD@ for A4GL_SQLUID and
A4GL_SQLPWD, the login used for DATABASE and DEFINE LIKE at compile
time and for the procedural DATABASE statement at run time. The old
configure.in had --with-sqluid/--with-sqlpwd and AC_SUBST for both.
The rewritten configure.ac had neither, so the placeholders reached
the installed aubitrc verbatim.

The runtime then read them as credentials and presented them to the
server, so every connection failed with

-951 Incorrect password or user @SQLUID@ is not known on the
database server.

A machine set up before the rewrite keeps working, because the
personal ~/.aubit4gl/aubitrc written by the older configure sets both
to empty and is read last, masking the broken value. Only a fresh
install, or a user whose personal rc lacks those lines, sees the
failure - which is why this did not show up locally.

Restores both options, defaulting to empty. Empty is the right
default: it means "connect as the current user", and matches what the
previous build produced when neither option was given.

Four other placeholders were leaking the same way and are now
substituted too, aubitdir_src to the source root and the rest to
empty. An unsubstituted @NAME@ is never a usable value - it reaches
the runtime as that literal string. Only @PG_COPTS@ remains, on a line
that is already commented out and marked as not set.

configure regenerated with autoreconf.

esqlc: INT8 host variables on older CSDK, and safer error message handling

Four fixes in the Informix driver.

1. Build failure on a CSDK that does not know BIGINT.

Three host variables were declared "bigint", a type that only exists
in a CSDK new enough to know BIGINT; older ones fail to compile with
"unknown type name 'bigint'". Two other uses in this same file were
already guarded by CBIGINTTYPE - that guard had simply never been
applied to these three.

They are now guarded the same way, falling back to "int8", which
esqlc rewrites to ifx_int8_t before the C compiler sees the token.
That is the 12 byte struct rather than a scalar, so the fallback
converts with ifx_int8cvasc/ifx_int8toasc - a decimal string being
the only conversion that keeps all 64 bits - and binds as INT8,
since a CSDK without CBIGINTTYPE has no BIGINT to bind to either.

The two branches deliberately use different variable names. esqlc
does not evaluate the #if; it records every declaration it walks
past, so a shared name leaves the last one winning and the bigint
branch gets marshalled as ifx_int8_t. That still compiles, and
silently reads 12 bytes out of an 8 byte variable.

2. Error text reaching the caller with its parameter unsubstituted.

get_sqlerrm() relied on GET DIAGNOSTICS to fill in the message
parameter. Not every CSDK does, so a caller could be shown
"user %s is not known" instead of being told which user was
rejected.

3. Message templates used as printf format strings.

get_errmsg() handed the template from rgetmsg() to sprintf with a
single argument. Informix has templates carrying up to four
conversions, so the remaining ones were read off the stack.

Both now go through one helper that substitutes sqlca.sqlerrm
textually and drops any conversions left over, so text supplied by
the server is never used as a format.

4. An unset SQLPWD became an empty password.

acl_getenv() returns an empty string for a variable that is not set,
never a null pointer, so initPassword() has to use the
_not_set_as_0 form the way initUser() already does. With the plain
form a user name with no password was presented as USER x USING '',
which the server refuses with -951 - indistinguishable from a wrong
password. That case now falls back to a connection as the current
user, and warns that the configured name could not be used.

Also adds debug to the connect path: the database, the user name and
where it came from, and on failure the sqlcode and sqlerrm, which is
where the name the server actually saw appears. The password itself is
never logged.

4glc: emit INT8 rather than the token name for BIGINT/INT8 columns

The Informix sqlpack rendered an INTEGER8 column type as the literal
string "INTEGER8" - the internal token name, not a SQL type. Every
neighbouring rule emits the real spelling (SERIAL8 gives "SERIAL8"),
so this one was the odd one out.

The server rejected the resulting DDL with -9628 "Type (integer8) not
found", which made BIGINT and INT8 unusable in CREATE TABLE and in any
other statement naming the type, a cast included.

Now emits INT8: accepted by every Informix version where the type
exists (BIGINT needs 11.x), and matching the DTYPE_INT8 the runtime
already uses for these columns. Also records the DDL_INT8 feature
marker, as the surrounding types do.