Aubit 4GL SVN-Code

odbc: sqlex.c and array.c still passed 32 bit length indicators

r13115 fixed the SQLLEN mismatches in sql.c, but the plugin is built from
four files and two more had the same fault, declared with SDWORD rather than
through the SQLLEN fallback:

sqlex.c A4GL_odbc_get_blob_data_int SDWORD i -> SQLGetData arg 6
array.c static SDWORD outlen[512] -> SQLBindCol arg 6

SDWORD is 4 bytes on LP64 while those parameters are SQLLEN *, 8 bytes, so the
driver writes 8 bytes into a 4 byte object - a warning before gcc 14 and an
error since. The unixODBC build stopped on the first of them:

sqlex.c:780:70: error: passing argument 6 of 'SQLGetData' from incompatible
pointer type [-Wincompatible-pointer-types]

and array.c would have followed with three more at SQLBindCol. Both are now
SQLLEN, which the bundled-header SQLITEODBC build still gets from the fallback
in a4gl_lib_sql_odbc_int.h. Every use of either variable is a comparison,
sum or size argument, all of which read the same with the wider type.

Checked against the unixODBC 2.3.12 headers (unixodbc-dev, Ubuntu 24.04):
before this change sqlex.c gives exactly the reported error and array.c the
three that would follow; after it all four files compile, and the unixodbc
make target builds libSQL_unixodbc.so with the Makefile's own flags. Also
clean against the Informix CLI headers (IFXODBC, 64 bit SQLLEN) and the
bundled tools/odbctest/incl set (SQLITEODBC, no SQLLEN at all). No other
SDWORD or SQLINTEGER in the plugin is passed where ODBC wants an SQLLEN.

OPEN FORM: pass the FORM variable's member, not the struct

A FORM variable is generated as

static struct { long objectid ; } list;

and OPEN FORM emitted A4GL_open_gui_form(&list,...) against a parameter
declared long* (API_ui.spec). That only worked because objectid happens to be
the single member and so shares the struct's address; to the C compiler it is
a type error, and one that gcc 14 refuses:

error: passing argument 1 of 'A4GL_open_gui_form' from incompatible pointer
type; expected 'long int *' but argument is of type 'struct <anonymous> *'

so tools/test/gui/calc.4gl could not be compiled. The member is now passed
explicitly - &list.objectid - which is the same address, so nothing changes at
runtime and the plugin API is left alone. The backends do write through that
pointer (*form_variable = (long)tlw in ui_glade), so long* is the right type
for it to keep.

While there: the name emitted here comes from the command as a plain
identifier rather than a variable usage, so it was not going through the scope
prefixing that r13117 added - under MARK_SCOPE the form was declared M_list and
opened as list. It is now looked up by name to find its scope, the same way the
CODE block aliases do, so declaration and use agree again. This could not have
shown up before, as the statement did not compile either way.

defprog.4gl calls time() in a CODE block without including <time.h>; it does
now, as clock.4gl does for usleep() since r13116.

Checked on the 142-module corpus: 112 compile where 110 did, the two being
calc.4gl and defprog.4gl, with nothing that compiled before failing now, and
the results identical with MARK_SCOPE and MARK_SCOPE_MODULE set.

Declare the 4GL-callable builtins where generated code can see them

Compiling a 4GL program that calls a4gl_get_ui_mode() fails:

error: implicit declaration of function 'aclfgl_a4gl_get_ui_mode';
did you mean 'aclfgl_a4gl_get_info'? [-Wimplicit-function-declaration]

The function exists (lib/libaubit4gl/fglwrap.c) and is prototyped in
a4gl_libaubit4gl.h - but that is the library include path, and generated code
uses the other one (a4gl_incl_4glhdr.h -> a4gl_incl_4gldef.h), so it never sees
the declaration. Implicit declarations were legal C89 and are an error in gcc
14, so what used to be a warning now stops the compile.

a4gl_get_ui_mode was not alone. Every name in lib/generated/std_funcs.c was
compiled as a call against the generated-code include path: 23 of them are
implemented in lib/libaubit4gl with the usual convention and had no prototype
there. All 23 are declared in a4gl_incl_4gldef.h now, which both paths include,
and the 16 declarations that existed in a4gl_libaubit4gl.h (one of them split
over two lines) are removed so there is a single source of truth, as are four
local prototypes at the top of builtin.c that now duplicate it.

A4GL_endis_fields goes the same way: the generator emits a call to it for the
field controls (print_endis_* in cmds_funcs.c) and it too was declared only in
a4gl_libaubit4gl.h. That is what stopped tools/test/gui/gui.4gl and
hello-gui.4gl from compiling; both do now.

Signatures were checked against the definitions, not against other headers.

Checked on 142 modules from tools/ and the test suite: 110 compile where 108
did, the two gui programs being the difference, and no module that compiled
before fails now. The same holds with MARK_SCOPE set. libaubit4gl builds with
no redundant-declaration warnings.

Not fixed here, found by the same scan and worth a look on their own:
- the DDE family, winexec, winexecwait and fgl_strtosend are listed as
builtins but are defined taking char* arguments, while the compiler emits
aclfgl_<name>(nargs) like every other builtin - so they cannot be called
from 4GL as they stand
- a4gl_dump_screen, a4gl_load_datatype, set_page and the *_rowid_s family are
listed as builtins with no implementation anywhere - a link error if called
- about 20 more A4GL_* functions the generator emits are declared only in
a4gl_libaubit4gl.h; each is the same latent error for whichever statement
emits it (menus, PDF reports, ESQL cursor state)

C back end: make MARK_SCOPE work

A4GL_MARK_SCOPE (and MARK_SCOPE_MODULE) prefixes variables with their scope -
G_ for globals, M_ or M_<module>_ for module variables, L_ for locals - so a
4GL name cannot collide with a C one. For the C back end it only ever renamed
the DECLARATION: every use still emitted the bare name, so a module with a
variable in it produced

static long M_dup ;
...
dup=0;

and did not compile. Only the C# back end, which applies the prefix wherever a
name is written, actually worked. So the one setting meant for this problem
could not be used for it.

The declaration and every use now take the name from one function,
scoped_variable_name(), so the two cannot drift apart again - expressions,
assignments, function and report parameter binding, nullify, dynamic arrays,
the object list and COPYBACK all go through it.

- system variables (status, sqlca, int_flag...) live in the library and keep
their names; a use is looked up to recognise them, as only the definition
records that

- class members and associative arrays keep the plain name: they are declared
through their own paths (objData->..., the ASSOCIATE_ macros)

- simple and object function parameters had no scope recorded at all, so they
were never prefixed; they are now marked local, as record and reference
parameters already were

- a CODE block is hand written C that names variables as the 4GL wrote them,
so each variable a block mentions is #defined to its scoped name for the
length of the block and #undef'd after. Only the block sees the aliases, so
generated code keeps the protection. Without this every tool with embedded
C - 4glpc, asql, adbschema, a4gl - failed to compile under the flag.

Checked on 142 modules from tools/ and the test suite compiled three ways - no
flag, MARK_SCOPE, MARK_SCOPE_MODULE: the same 108 compile in all three, and the
34 that fail fail identically, all for reasons that predate this. With no flag
set the generated C is byte for byte what it was, bar the cursor and prepare
identifiers that differ on every compile. Runtime output is identical in all
three modes for a program exercising globals, module variables, locals,
records, arrays, dynamic arrays, a report and variables called dup, read, write
and close; for both OO test programs; and for a 4glpc built with the flag and
then used to compile and run a program. ESQL/C output compiles through Informix
esql with either flag. A clean export of r13115 with this change builds with 0
errors and the same 361 warnings as without it.

Two things the flag cannot do: C outside the module must use the prefixed name
of a GLOBALS variable, and if a name is both a 4GL variable and a struct member
used across CODE blocks the aliasing renames the member too - a compile error,
not a silent change of meaning.

The description of A4GL_MARK_SCOPE said it adds the module name, which is what
MARK_SCOPE_MODULE does; corrected, and MARK_SCOPE_MODULE is now described too.

Generated code: do not include <unistd.h>

r13105 added <unistd.h> to a4gl_incl_4glhdr.h so that a CODE block calling
usleep would not rely on an implicit declaration, which gcc 14 rejects. That
header also declares dup, read, write, close, link and access, and generated C
puts module and GLOBALS variables at file scope under their 4GL names - so any
program with a variable of such a name stopped compiling:

error: 'dup' redeclared as different kind of symbol

Those are ordinary 4GL variable names: such programs compiled in 1.6.3 and up
to r13104. The include is removed again, and the two files in the tree that
need the header now ask for it themselves in a CODE block - tools/test/clock.4gl
for usleep() and tools/test/html/html_report.4gl for unlink(). Every other CODE
block calling a POSIX function is in a file that already reaches the header
through tools/asql/simple.h; all 243 versioned .4gl files were scanned for this.

Checked on clean exports of r13115 built with and without the change: configure
and make both succeed, with 0 errors and the same 361 warnings, and not one
diagnostic appears or disappears. The files r13105 was aimed at are not part of
any default target, which is why the build does not move either way.

A variable can still collide with stdio.h, string.h or stdlib.h - index, time
and system, say. A4GL_MARK_SCOPE covers that case.

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.